Releases: oauth-wg/oauth-v2-1
Releases · oauth-wg/oauth-v2-1
draft-ietf-oauth-v2-1-12
Changes
- Added DPoP and Step-Up Auth to appendix of extensions
- Updated reference for case insensitivity of auth scheme to HTTP instead of ABNF (#186)
- Corrected an instance of "relying party" vs "client" (#169)
- Moved client_id requirement to the individual grant types
- Updated language around client registration to better reflect alternative registration methods such as those in use by OpenID Federation and open ecosystems
- fixed typos #185
- consolidated description of serialization #181 #190
draft-ietf-oauth-v2-1-11
Changes discussed at May 14 Interim
- resolves client credentials encoding issue #128
- Recommend against defining custom scopes that conflict with known scopes #163
- Explicitly mention that Bearer is case insensitive #166
Editorial Changes
- Remove duplicate "are" by @MozharAlhosni in #175
- clarify expires_in is a JSON number by @panva in #172
- Minor fix by @MozharAlhosni in #173
- Added paragraph about interaction between RO and AS
New Contributors
- @MozharAlhosni made their first contribution in #175
- @panva made their first contribution in #172
Full Changelog: draft-ietf-oauth-v2-1-10...draft-ietf-oauth-v2-1-11
Draft 10
- Clarify that the client id is an opaque string
- Extensions may define additional error codes on a resource request
- Improved formatting for error field definitions
- Moved and expanded "scope" definition to introduction section
- Split access token section into structure and request
- Renamed b64token to token68 for consistency with RFC7235
- Restored content from old appendix B about application/x-www-form-urlencoded
- Clarified that clients must not parse access tokens
- Expanded text around when
redirect_uri
parameter is required in the authorization request - Changed "permissions" to "privileges" in refresh token section for consistency
- Consolidated authorization code flow security considerations
- Clarified authorization code reuse - an authorization code can only obtain an access token once
Draft 09
- AS MUST NOT support CORS requests at authorization endpoint
- more detail on asymmetric client authentication
- sync CSRF description from security BCP
- update and move sender-constrained access tokens section
- sync client impersonating resource owner with security BCP
- add reference to authorization request from redirect URI registration section
- sync refresh rotation section from security BCP
- sync redirect URI matching text from security BCP
- updated references to RAR (RFC9396)
- clarifications on URIs
- removed redirect_uri from the token request
- expanded security considerations around code_verifier
- revised introduction section
Draft 08
- Swap "by a trusted party" with "by an outside party" in client ID definition
- Replaced "verify the identity of the resource owner" with "authenticate"
- Clarified refresh token rotation to match RFC6819
- Added appendix to hold application/x-www-form-urlencoded examples
- Fixed references to entries in appendix
- Incorporated new "Phishing via AS" section from Security BCP
- Rephrase description of the motivation for client authentication
- Moved "scope" parameter in token request into specific grant types to match OAuth 2.0
- Updated Clickjacking and Open Redirection description from the latest version of the Security BCP
- Moved normative requirements out of authorization code security considerations section
- Security considerations clarifications, and removed a duplicate section
- Updated acknowledgments
Draft 07
- Removed "third party" from abstract
- Added MFA and passwordless as additional motiviations in introduction
- Mention PAR as one way redirect URI registration can happen
- Added a reference to requiring CORS headers on the token endpoint
- Updated reference to OMAP extension
- Fixed numbering in sequence diagram