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

[Rohan Mahy <[e-mail]>]

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]
>
>