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

[Vladimir Dzhuvinov]

I agree this is a good and sensible approach. I like the rework 
argument, as a mean to nudge people in the right direction :)

Regarding CIBA login_token_hint, in some ways it can be more dangerous 
that a plain login hint or even an id_token_hint, because it may get 
implemented as a semi permanent token that links the user & their authN 
device to the IdP. For web based IdP this binding is facilitated by a 
session cookie in the browser, but in a CIBA app this binding and the 
login hint may get conflated. One also has to be careful not to leak 
private data to the RP via the login_hint_token - I've seen one such 
implementation attempt (but that's another topic).

Vladimir Dzhuvinov

On 29/03/2022 19:38, Vittorio Bertocci wrote:
> 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/6ef8785b/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/6ef8785b/attachment.p7s>