[OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD-JWT architecture feedback)

[Kristina Yasuda <[e-mail]>]

The reason why section 10.11 recommends JWT type to be defined by the
use-case is because SD-JWT specification is not meant only for one kind of
use-case/architecture. SD-JWT document does not define a stand alone
credential format for issuer-holder-verifier model, SD-JWT VC document is
intended to serve that purpose. Theoretically, SD-JWT could be used with
any other JWTs (such as ID Tokens, Access Tokens, JARM JWTs, etc.) which
have their own typing. So giving SD-JWT construct itself an explicit type
is not very helpful (though still defined for the cases where no
example+sd-jwt media type is defined), and might even become the source of
the confusion if developers start using a type defined in the SD-JWT
document instead of a type defined in documents like SD-JWT VC.

This is why the SD-JWT draft already defined both application/sd-jwt
and +sd-jwt Structured Syntax for use-cases like application/vc+sd-jwt in
SD-JWT VC, and if I am interpreting the thread correctly, sounds like that
is a good balance and is the way to go.

Hope this helps,
Kristina



On Sun, Sep 22, 2024 at 7:40 PM Rohan Mahy <[e-mail]> wrote:

> But when you *don't* use the public key to secure more than a single type
> of application message (unsurprisingly a very common use case), there is no
> issue. Given that the current document defers to profiles all decisions
> about which validation claims to require, which is a much more serious
> likely security concern, I think a default type should be defined,
> mentioned in security considerations, and its use (or not) can be profiled
> as appropriate.
> Thanks,
> -rohan
>
> On Sun, Sep 22, 2024 at 10:24 AM David Waite <[e-mail]>
> wrote:
>
>> There are security issues from this however if the public key is used to
>> secure more than a single type of application message - say a message
>> normally used to indicate someone is logging out accidentally being
>> accepted for log-in or as a valid session token on a website.
>>
>> In this scenario, you need some way to differentiate the two messages
>> reliably (across many potential interoperable implementations), and making
>> them different media types is the best current practice.
>>
>> -DW
>>
>> On Sep 22, 2024, at 10:52 AM, Rohan Mahy <[e-mail]> wrote:
>>
>> 
>> Hi,
>> If someone defines a new profile application/foobar-audit-system and it
>> has sd-jwt, jwt, and sd-cwt versions, it seems perfectly reasonable to have
>> a fine-grained explicit media type application/foobar-audit-system+sd-jwt.
>> That said, there are times when someone just wants an sd-jwt with an
>> unspecified profile. In this second case, it makes more sense to me to also
>> register application/sd-jwt. The implementor should fill in whichever form
>> they are using in the `typ` header.
>>
>> Thanks,
>> -rohan
>>
>> On Sat, Sep 21, 2024 at 12:17 PM Michael Jones <
>> [e-mail]> wrote:
>>
>>> Actually, the JWT BCP (which we were both authors of) does not recommend
>>> using a single media type.  Rather, it recommends using a specific
>>> media type suffix in the “typ” values
>>> <https://www.rfc-editor.org/rfc/rfc8725.html#name-use-explicit-typing>:
>>>
>>> When explicit typing is employed for a JWT, it is *RECOMMENDED* that a
>>> media type name of the format "application/example+jwt" be used, where
>>> "example" is replaced by the identifier for the specific kind of JWT.
>>>
>>>
>>>
>>> SD-JWT is doing the same thing, recommending the use of the media type
>>> suffix “+sd-jwt”.
>>>
>>>
>>>
>>> This enables more fine-grained explicit typing.  For instance, when
>>> doing explicit typing for an SD-JWT in the Example use case, the “typ”
>>> value would be “example+sd-jwt”.  This can then be distinguished from an
>>> SD-JWT for the Other use case, which would use the “typ” value
>>> “other+sd-jwt” – meeting the goal of explicit typing.
>>>
>>>
>>>
>>>                                                                 -- Mike
>>>
>>>
>>>
>>> *From:* Dick Hardt <[e-mail]>
>>> *Sent:* Saturday, September 21, 2024 9:16 AM
>>> *To:* Daniel Fett <[e-mail]>
>>> *Cc:* [e-mail]; [e-mail]
>>> *Subject:* [OAUTH-WG] Re: SD-JWT architecture feedback
>>>
>>>
>>>
>>> …
>>>
>>>
>>>
>>> *Explicit Typing*
>>>
>>> Why leave the typing in the header to be determined by the application
>>> (10.11), and not just be 'sd-jwt' and be REQUIRED?
>>>
>>> We had extensive discussions around typing, please refer to the
>>> following issues:
>>>
>>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/267
>>>
>>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327
>>>
>>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/345
>>>
>>>
>>>
>>> Those issues don't really address the point.
>>>
>>>
>>>
>>> Per RFC 8725: JSON Web Token Best Current Practices (rfc-editor.org)
>>> <https://www.rfc-editor.org/rfc/rfc8725.html#name-use-explicit-typing> --
>>> the best practice would be to have a single type that would allow a library
>>> to know it is an SD-JWT. If additional context is needed, perhaps that
>>> should be a different header property?
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>