Hi all, Draft 17 of OAuth 2.1 addresses most of the outstanding feedback.
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-17.html Ahead of IETF 127 I'd like to get your eyes on the few remaining issues. It would be great to get some feedback on these before IETF 127 so we can save some time during the sessions, because I'm sure we'll have a packed agenda. #274 <https://github.com/oauth-wg/oauth-v2-1/issues/274>: an RFC6749/RFC6750 conflict between the access token character definition and the allowed list of characters that can be sent in an HTTP header. I propose we close with the changes in #273 <https://github.com/oauth-wg/oauth-v2-1/pull/273>, defining access tokens as the less permissive token68 character set. #266 <https://github.com/oauth-wg/oauth-v2-1/issues/266>: the IANA registry says invalid_client is allowed in an authorization response, but that's not defined in RFC6749. It would be useful, so we should add it. #265 <https://github.com/oauth-wg/oauth-v2-1/issues/265>: let's be consistent with "apps" vs "applications". The Native Apps BCP is the only doc that uses "apps" everywhere, should we change that to "applications" for consistency? #215 <https://github.com/oauth-wg/oauth-v2-1/issues/215>: there is a clear need for a "resource" token response parameter like "scope", but this is out of scope for OAuth 2.1 (no pun intended). Let's adopt the draft that adds it so we can reference it though. Please comment on the issues or on the list if you have anything to add. I'd be super happy to close out one or more of these to avoid needing discussion time during the meeting. --- Aaron Parecki
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
