Thanks for the work on this document Mike. Regarding the questions for the working group:
1. My preference is for a single document. 2. The scope of the changes should be constrained to only what is necessary to address the issue that brought us here, which is JWT Client Assertion Authentication. Updates beyond that scope will needlessly introduce confusion and interoperability problems as well as maintenance and support burden and/or unnecessarily hinder progress of the work. 3. I would like to see the WG produces something that address the issue in a timely and responsible manner. The current draft is not well positioned to do either. On Fri, Jan 31, 2025 at 8:57 AM Filip Skokan <panva...@gmail.com> wrote: > 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 > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
