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

[Vittorio Bertocci]

Thanks Vladimir for the extra context!
Excluding the hint cases (it's a hint, hence not a credential - in the same
mental space as login_hint for me),all the other cases would seem solvable
by using a specific audience (hence an access token) rather than an
IDtoken. I understand that the existing logic is using an IDtoken, but in
order to handle the stronger type you'd need to change processing logic
anyway- hence it seem at least a theoretical possibility to go even
further and change to an AT directly :) what do you think?

On Tue, Mar 29, 2022 at 9:27 AM Vladimir Dzhuvinov <vladimir at connect2id.com>
wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> 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/cfc561d3/attachment.html>