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, 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? 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/ 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? 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. Regards, OS, ART AD On Wed, May 21, 2025 at 12:05 PM Daniel Fett <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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 >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
