Some follow-ups from my side:
- I see that the API documentation has not been rolled back yet as it still described the `expirationDate` with a maximum value of 6 months that also defaults to 6 months.
- Similar for the general documentation.
- I see value in an expiration date being there. Where ORG admins can globally configure what the default expiration date would be if not given (which can be infinite), and if there should be a maximum expiration date, what should that maximum be? Customer A could then say. 1 There is no enforced expiration date, and 2 by default it does not expire. Customer B could say. 1 There is no enforced expiration date, it can even have no expiration date at all, but 2. If no expiration date (including infinity) is specifically chosen, we default to 1 year. And customer C could then say: We have an enforced expiration date, of max 2 years, and we default to 6 months if no expiration date is specifically given. You can still put the default global configuration for new customers as enforced expiration date of max 6 months and put 6 months as default when not given, as long as you allow them to change this global setting. By doing this you are respecting a diverse group of customers, to make their own conscious security decisions.
- I can also see merit in other functionality such as email notifications being send when PATs are about to expire. Sending email notifications when they haven’t been used in a long time or even delete them a bit later (as long as customers can switch off this functionality, as we have this already through workflows). Allow customers to perform certification on their own or on others Personal Access Tokens. And allow org admins to specify which identities (like specific service accounts and specific employees) may create PATs and which identities may not create PATs (for example through governance group and/or role membership).
Kind regards,
Angelo