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
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
