I've published draft-jones-oauth-rfc7523bis<https://www.ietf.org/archive/id/draft-jones-oauth-rfc7523bis-00.html>, which proposes replacing RFC 7523<https://www.rfc-editor.org/rfc/rfc7523> (JWT Assertions) and proposes corresponding updates to RFC 7521<https://www.rfc-editor.org/rfc/rfc7521> (Assertions Framework), RFC 7522<https://www.rfc-editor.org/rfc/rfc7522> (SAML Assertions), RFC 9101<https://www.rfc-editor.org/rfc/rfc9101> (JAR), and RFC 9126<https://www.rfc-editor.org/rfc/rfc9126> (PAR), as discussed during Monday's interim. See the deck that Joseph Heenan and I presented<https://datatracker.ietf.org/meeting/interim-2025-oauth-04/materials/slides-interim-2025-oauth-04-sessa-private-key-jwt-aud-issues-00.pdf>.
Note that corresponding updates have also been published to OpenID Connect Core, OpenID FAPI 1, OpenID FAPI 2, and OpenID CIBA Core. The discussion on Monday resulted in these questions for the working group: 1. The draft proposes to update affected specs other than RFC 7523, rather than replacing them. This was done to make the changes easier to review. See the four sets of updates beginning at Section 9<https://www.ietf.org/archive/id/draft-jones-oauth-rfc7523bis-00.html#name-updates-to-rfc-7521>. Do we want to update the affected specs from this single "bis" document or create individual "bis" documents for each of them? 2. The draft proposes to uniformly update the audience values in security tokens sent to the authorization server to the AS's issuer identifier. This includes client authentication JWTs, authorization grant JWTs, and Request Object JWTs. This is a change in some cases and a narrowing to a single already-acceptable specified audience choice in others. Do we want to uniformly use the issuer identifier for token audiences, or have a different special case audience value of the token endpoint URL for authorization grant JWTs? 3. Are people in favor of adopting the draft as-is and then making any changes wanted by the working group to the adopted spec or are there specific changes people believe we should make before adoption? As a reminder (quoting from an IETF call for adoption), "Adoption does not mean a document is finished, only that it is an acceptable starting point." Thanks to all who put in substantial work over the last few months to get us to this point! -- Mike
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
