Hi all, I am new to IETF so apologies if I'm not doing this correctly. I had a few suggestions for things to add to the 2.1 spec based on scenarios encountered from running a large authorization server. Let me know your thoughts or if I should be using a different channel (like github) to contribute issues/suggestions.
-- In “3.2.3. Token Response”, I think it’s worth defining a refresh token expiration parameter. This could be useful both for refresh token rotation (as discussed in section 4.3.1.) as well as supporting user selection of shorter-lived access. A quick search suggests that there’s some existing usage of refresh_token_expires_in as a parameter name (Microsoft, GitHub). In “3.2.4. Error Response”, it would be worth adding access_denied as a valid error code here for cases where the authorization server denies the request. (For example, an enterprise user granted access in the past, but their admin has since disabled the client or scope for their org.) In “3.2.4. Error Response” and “4.1.2.1. Error Response”, is it worth adding another error code like access_denied_by_authorization_server (bad name, I know) for cases where the authorization server feels it’s useful and appropriate to distinguish between resource owner denial and authorization server denial? This may not be needed as authorization servers are already free to define their own error code extensions, but a single umbrella error code could be useful for simpler implementations. In “3.2.4. Error Response” (and maybe also 5.3.1), it would be useful to have some sort of “display_uri” parameter that the authorization server can provide for RPs to open in a browser if they are able. This display_uri could be used to show a richer error to the resource owner or even be used for recovery (e.g. reauth). We could also try to spec out what a full-blown token endpoint-initiated recovery flow might look like. In “4.1.2. Authorization Response”, I think we should say that the authorization server MUST return a scope parameter if the RP included scope in the request and the granted scopes differ from the requested scopes. This allows RPs to be informed if the resource owner only grants partial consent. - Nick Watson
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
