Orie, Thanks again for the review and engagement on this. A draft -20 has been published incorporating these changes and is hopefully sufficient to clear the DISCUSS.
On Fri, May 23, 2025 at 3:10 PM Brian Campbell <bcampb...@pingidentity.com> wrote: > Thanks Orie for a productive and enjoyable discussion yesterday. I've > updated the > https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/576 PR as > we discussed and incorporated changes for a number of your comments and > nits. > > On Thu, May 22, 2025 at 1:05 PM Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> A proposed change to the restrict the KB-JWT's aud to a single value is >> in this PR >> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/576 >> >> Orie and I have some time scheduled later today to chat directly and try >> and get to a mutually agreeable place on the rest of it. >> >> >> >> On Wed, May 21, 2025 at 5:22 PM Orie <o...@or13.io> wrote: >> >>> I think we are close, you wrote: >>> >>> > Verifiers of either still have to adhere to >>> https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3 >>> >>> Case analysis produces the following: >>> >>> - All audience are recognized, and all tokens are valid (good) >>> - At least one audience is recognized in each token (ok) >>> - Either token contains only audiences that are not recognized (must >>> reject) >>> >>> Restricting KBT to a single audience seems like an improvement. >>> >> >> >> >> >>> >>> > In effect that guidance does not apply because most SD-JWTs are >>> intended for use at *any* relying party or application and (borrowing >>> language from that BCP) determining whether the SD-JWT is being used by an >>> intended party or was substituted by an attacker at an unintended party is >>> accomplished by the SD-JWT being bound to a key via "cnf" claim and proof >>> of possession of that key on presentation via the KB-JWT. >>> >>> I agree with this. >>> >>> So there exists a case where a KB-JWT audience is recognized and the >>> SD-JWT audience is present, but not recognized. >>> This results in verification failure, per the guidance in Section 4.1.3 >>> of RFC7519. >>> >>> I spent some time trying to come up with suggestions for Section 7.1 and >>> 7.3 that would address this, but they all felt redundant to >>> https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3 >>> >>> Per the clarifications you and Daniel have provided I now believe the >>> following is true (please correct me if I am wrong): >>> >>> A relying party MUST reject SD-JWT+KB when SD-JWT or KB-JWT contain >>> audience values and none of the audience values are associated with the >>> relying party. >>> >>> Since none of the guidance regarding audience from BCP225 or RFC7519 >>> cleanly applies to SD-JWT+KB (a 2 token model, with different token >>> issuers), would you consider something similar to the sentence above just >>> before the final sentence of Section 7.3 which ends with: >>> >>> > If any step fails, the presentation is not valid and processing MUST >>> be aborted. >>> >>> I still think clearer guidance to profiles of the form "aud" in SD-JWT >>> with Key Binding is not recommended would make sense, but that is just a >>> non blocking comment. >>> >>> Regards, >>> >>> OS >>> >>> >>> >>> >>> On Wed, May 21, 2025 at 2:08 PM Brian Campbell < >>> bcampb...@pingidentity.com> wrote: >>> >>>> >>>> >>>> On Wed, May 21, 2025 at 12:07 PM Orie <o...@or13.io> wrote: >>>> >>>>> Per: >>>>> - >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-19#verifier_verification >>>>> - >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-19#section-7.1-4.6 >>>>> - >>>>> https://datatracker.ietf.org/doc/html/rfc8725#name-use-and-validate-audience >>>>> >>>>> Are you saying that the guidance from the JWT BCP above does not apply >>>>> to SD-JWT, >>>>> >>>> >>>> In effect that guidance does not apply because most SD-JWTs are >>>> intended for use at *any* relying party or application and (borrowing >>>> language from that BCP) determining whether the SD-JWT is being used by an >>>> intended party or was substituted by an attacker at an unintended party is >>>> accomplished by the SD-JWT being bound to a key via "cnf" claim and proof >>>> of possession of that key on presentation via the KB-JWT. >>>> >>>> >>>> >>>>> and that it is valid for a verifier of a KB-JWT to accept an SD-JWT >>>>> which contains an audience that it does not recognize? >>>>> >>>> >>>> Verifiers of either still have to adhere to >>>> https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3 >>>> >>>> >>>> >>>>> If thats the case, you still end with 1 or more audiences, they are >>>>> just in 2 different tokens, possibly targeted at different verifiers (by >>>>> design). >>>>> I would still want to understand if there is any impact from >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/ >>>>> >>>> >>>> I think we are thinking that it would be worthwhile to restrict the aud >>>> of the KB-JWT to a single value. I don't think anything else/more would be >>>> helpful or appropriate. That is what I was trying to suggest (and ask for >>>> your approval of such) in my initial reply to the ballot position email. >>>> >>>> >>>> >>>>> >>>>> >>>>> Perhaps another way to read >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-19#section-7.3-6 >>>>> Is that SD-JWT aud claims are processed by downstream applications, >>>>> and not at the point of SD-JWT + KB-JWT verification? >>>>> >>>> >>>> That would not be a valid reading in my understanding of things. Both >>>> the SD-JWT + KB-JWT are subject to the normal validation rules. That should >>>> be implicit from them being JWTs but it's also reiterated in the validation >>>> steps in 7.1 and 7.3. >>>> >>>> >>>> >>>>> This is the essence of my discuss, and I don't have a particular >>>>> outcome in mind here, I just wanted to understand this better. >>>>> >>>> >>>> Are we moving in the direction of better understanding? I don't >>>> honestly feel like I am personally. But my understanding isn't the goal >>>> here. >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> >>>>> OS, ART AD >>>>> >>>>> >>>>> >>>>> On Wed, May 21, 2025 at 12:05 PM Daniel Fett <m...@danielfett.de> >>>>> wrote: >>>>> >>>>>> Thanks for your Review, Orie! >>>>>> >>>>>> Comments inline. >>>>>> Am 21.05.25 um 17:21 schrieb Orie: >>>>>> >>>>>> Thanks Brian, >>>>>> >>>>>> There is a related comment regarding the typ for kb+jwt and its >>>>>> requirements. >>>>>> Which I pulled out from this discuss block, but which might explain a >>>>>> bit more the motivation for the discussion. >>>>>> >>>>>> Inline for the rest: >>>>>> >>>>>> On Tue, May 20, 2025 at 3:29 PM Brian Campbell < >>>>>> bcampb...@pingidentity.com> wrote: >>>>>> >>>>>>> Thanks for the review Orie. >>>>>>> >>>>>>> In hopes of expediting discussion towards a resolution to the >>>>>>> blocking comments, I'm going to reply separately to the DISCUSS here >>>>>>> first. >>>>>>> That's inline below. >>>>>>> >>>>>>> On Tue, May 20, 2025 at 9:51 AM Orie Steele via Datatracker < >>>>>>> nore...@ietf.org> wrote: >>>>>>> >>>>>>>> Orie Steele has entered the following ballot position for >>>>>>>> draft-ietf-oauth-selective-disclosure-jwt-19: Discuss >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> DISCUSS: >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> ## Discuss >>>>>>>> >>>>>>>> ### Requirements for "aud" in SD-JWT and KB-JWT >>>>>>>> >>>>>>>> ``` >>>>>>>> 869 - aud: REQUIRED. The intended receiver of the Key >>>>>>>> Binding JWT. >>>>>>>> 870 How the value is represented is up to the protocol >>>>>>>> used and out >>>>>>>> 871 of scope of this specification. >>>>>>>> ``` >>>>>>>> >>>>>>>> Is there any need to comment on array vs single audience here, or >>>>>>>> guidance for >>>>>>>> profiles regarding this? >>>>>>>> >>>>>>> >>>>>>> My intuition thus far has been no (which probably explains why there >>>>>>> isn't more comment/guidance in the text). But I can't really think of a >>>>>>> reasonable reason to use multiple audience values in a KB-JWT. All the >>>>>>> usages that I'm aware of (not exhaustive, obviously, but a reasonable >>>>>>> sampling) only use a single value. And the text already kinda implies >>>>>>> that >>>>>>> it's expected to be a single value. So maybe it'd be better to just make >>>>>>> that (a single value as a string) an explicit restriction? >>>>>>> >>>>>> >>>>>> OS> Given SD-JWT is new, and that >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/ is in >>>>>> progress, I wanted to understand the group thinking on this topic. >>>>>> >>>>>> I think I agree with Brian on this. Adding the restriction for KB-JWT >>>>>> would make sense. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> ``` >>>>>>>> 1987 * aud (Audience), although issuers MAY allow individual >>>>>>>> entries in >>>>>>>> 1988 the array to be selectively disclosable >>>>>>>> ``` >>>>>>>> >>>>>>>> Consider addressing the security considerations for "aud" in one >>>>>>>> place, and >>>>>>>> commenting on the guidance for profiles of both SD-JWT and >>>>>>>> SD-JWT+KBs. >>>>>>>> >>>>>>> >>>>>>> The security considerations around "aud" are sufficiently different >>>>>>> that I'd be very hesitant to try and treat them together. >>>>>>> The "aud" claim is required in the KB-JWT while being totally >>>>>>> optional and unlikely, in most expected cases, to even appear in the >>>>>>> SD-JWT. >>>>>>> >>>>>> >>>>>> OS>``` >>>>>> It is required, but imo, underspecified. >>>>>> (...) >>>>>> >>>>>> It seems like the primary value for multiple disclosable aud in >>>>>> SD-JWT would be a case where the issuer knew the verifiers up front, and >>>>>> wanted to restrict which verifiers the holder could present too, without >>>>>> the verifiers learning about each other. >>>>>> I can imagine the healthcare related use cases might support this >>>>>> argument. >>>>>> >>>>>> >>>>>> ``` >>>>>> >>>>>>> >>>>>>>> Is it safe to allow selective disclosure within the audience claim? >>>>>>>> >>>>>>> >>>>>>> Noting that most/many SD-JWTs won't have an audience claim and that >>>>>>> bit of text is in a section talking about validity claims and when they >>>>>>> shouldn't be made selectively disclosable at all, I think it is safe. >>>>>>> Allowing selective disclosure within the audience claim means that the >>>>>>> verifier will see that the audience claim exists and the holder needs to >>>>>>> disclose the element that would make it acceptable to the verifier. But >>>>>>> cannot conceal the presence of the claim to bypass its intent. >>>>>>> >>>>>> >>>>>> OS>``` >>>>>> >>>>>> I think you end with a table like this (based on current >>>>>> requirements): >>>>>> >>>>>> aud | cardinality | disclosure >>>>>> SD-JWT ... OPTIONAL | 1 or more | OPTIONAL >>>>>> KB-JWT ... REQUIRED | 1 or more | REQUIRED >>>>>> >>>>>> SD-JWT "aud" is a superset of KB-JWT "aud"? >>>>>> >>>>>> There is no reason to assume that there is a natural relationship >>>>>> between the two. >>>>>> >>>>>> >>>>>> This is a lot of rope for profiles, can we give them better guidance >>>>>> / safer defaults? >>>>>> >>>>>> I don't know how we could provide reasonable guidance in the SD-JWT >>>>>> spec itself and I therefore think that the current approach to leave it >>>>>> unspecified is the correct one. >>>>>> >>>>>> -Daniel >>>>>> >>>>> >>>> *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.* >>> >>> -- _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
