Hello Mike,
thank you for a quick turnaround on these
As far as questions 1-3 go:
1. I believe a precise incision in the form of a single "bis" document
is fine but if these were individual documents it wouldn't hurt,
whatever we can get out the door faster.
2. We have not done the homework of understanding the impact of changing
anything but client authentication JWTs.
1. Ad JAR) There's no conflicting definition that would mention
anything but using RFC8414 issuer in RFC9101 and so I am in favour of
leaving it be in its current pre-bis state as the only change would be
forbidding the array style of audience. It is unnecessary. In the client
auth case we have conflicting definitions with MAY and SHOULD about the
token endpoint being used; We don't have that in JAR.
2. Ad authorization grant JWTs) Aaron pointed out in prior
discussions that these would better remain unchanged [^1], is that still
the case?
3. Ad SAML) I cannot imagine any changes being done here but will
admit that I would leave this with others who better understand how SAML
assertions are used today.
4. Bottom line I hope we can deal with just the issue at hand and
avoid changes to unaffected assertions.
3. Doesn't it sort of hinge on what we believe the right answer to 1) is?
[^1]: Question for Aaron, if authorization grant JWTs remained as is wrt.
to the audience claim, what about the added "typ"?
S pozdravem,
*Filip Skokan*
On Thu, 30 Jan 2025 at 20:03, Michael Jones <michael_b_jo...@hotmail.com>
wrote:
> 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
>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
