[Openid-specs-ab] OpenID Connect: Explicitly typed ID tokens and UserInfo

[Vladimir Dzhuvinov]

Hi Vittorio,

The mentioned use cases I know of:

  * Resource servers with access tokens that don't conform to RFC 9068

  * Implementations of token exchange

  * Implementations of the login_hint_token in CIBA, which may be issued
    by the OP or some other service and therefore can take any shape

One strong argument for this explicit typing has been to make it harder 
to swap or mix up tokens when developers implement JWT processing logic 
at some endpoint and we all make the occasional bug :) So this explicit 
typing was thought as extra defense against design and coding mistakes.

There is a third OIDC specific JWT that I didn't mention - the 
back-channel logout token. According to the SET RFC 8417 it can carry a 
"secevent+jwt" header, but I realised the current OIDC logout spec 
doesn't mention whether that's required or allowed.

Vladimir

Vladimir Dzhuvinov

On 29/03/2022 18:24, Vittorio Bertocci wrote:
> Hi Vladimir!
> We introduced explicit typing in the JWT access token profile - in 
> theory, that should be enough to distinguish as in all other JWTs 
> floating in OIDC are either IDtokens or don't strictly require 
> signature validation (eg userinfo ones coming from a direct connection 
> rather than redirects).
> What are the use cases where the extra info you are embedding there 
> leads to different processing logic?
> thanks
> V.
>
> On Tue, Mar 29, 2022 at 8:20 AM Vladimir Dzhuvinov via Openid-specs-ab 
> <openid-specs-ab at lists.openid.net> wrote:
>
>     *This message originated outside your organization.*
>
>
>     ------------------------------------------------------------------------
>
>     The classic OIDC appears to be no longer the hot topic here, but I
>     want to inform the WG that after resisting pressure from users for
>     some time we recently started supporting explicitly typed ID
>     tokens and UserInfo JWTs, the rationale being the prevention of
>     mix ups in applications with many types of JWTs floating around,
>     plus making it easier for code and people to determine the JWT
>     purpose by simply examining the "typ" (type) header and not having
>     to analyze the claims structure.
>
>     By explicit JWT typing I mean use of the optional "typ" header in
>     a JWT, something the JWT profile for access tokens for instance
>     uses (and other OAuth related specs that carry JWTs).
>
>     |{ "kid" : "1", "alg" : "RS256", "typ" : "id_token+jwt" }|
>
>     |{ "kid" : "1", "alg" : "RS256", "typ" : "userinfo+jwt" }|
>
>
>     I know this is non-standard and may likely break existing
>     validation code and client libraries. If you have thoughts or
>     feedback about this typing, good or bad, I'd love to hear it.
>
>     Vladimir
>
>     -- 
>     Vladimir Dzhuvinov
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220329/edce38f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220329/edce38f9/attachment.p7s>