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. >> ``` >> 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. Without profiles for kb+jwt, you are setting a security bar by leaving aud mandatory but not restricting it to a single value, is this the right security bar? For SD-JWT you are defining a suffix, and a media type... Which implies that you expect profiles, my reading of the bit about selective disclosure in the audience, seemed like encouraging the disclosability of that claim. Treating them together gives you a clean opportunity to call out their differences, but that's a style issue, I am more concerned about the guidance to profiles. When profiling SD-JWT, should both aud be arrays? should both be strings? should aud always be disclosable, so that the holder does not reveal verifiers that are known to the issuer to other verifiers? It's fine if the answers are "use case specific / it depends"... but given https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/ ... I would prefer to see something to the effect of: In absence of specific use case requirements "aud" SHOULD be a single string value. In absence of specific use case requirements when "aud" is an array, all values SHOULD / SHOULD NOT be disclosable. The BCP14 specifics above are not what matters to me, it's the guidance to profiles. If a SHOULD is used, it would be good to explain at least one reason why it is not a MUST / MUST NOT. 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"? This is a lot of rope for profiles, can we give them better guidance / safer defaults? ``` > Does the safeness vary between SD-JWT and KB-JWT? > > > It's not allowed and also not possible to make the audience claim > selective disclosable in the KB-JWT. So yes, it does vary, but it varies so > much that it's not a useful comparison. > OS>``` I agree, in absence of a more specific media type per the JWT BCP, I would recommend the following for "application/sd-jwt" and "application/kb+jwt" application/sd-jwt / application/*+sd-jwt ... OPTIONAL | 1 | OPTIONAL application/kb+jwt ... REQUIRED | 1 | REQUIRED Note that when "aud" is present in application/sd-jwt / application/*+sd-jwt, the aud in application/kb+jwt MUST match it exactly? ``` Happy to clear this discuss if there is revised guidance on recommended defaults, I'm not attached to particular guidance, I mostly wanted to understand how this interacts with https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/ > > > *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 -- [email protected] To unsubscribe send an email to [email protected]
