<div dir="ltr">Thanks Vladimir for the extra context!<div>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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 29, 2022 at 9:27 AM Vladimir Dzhuvinov <<a href="mailto:vladimir@connect2id.com">vladimir@connect2id.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<p><strong>This message originated outside your organization.</strong></p><br>
<hr><br>
</div>
<p>Hi Vittorio,</p>
<p>The mentioned use cases I know of:</p>
<ul>
<li>Resource servers with access tokens that don't conform to RFC
9068<br>
<br>
</li>
<li>Implementations of token exchange<br>
<br>
</li>
<li>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<br>
<br>
</li>
</ul>
<p>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.</p>
<p>There is a third OIDC specific JWT that I didn't mention - the
back-channel logout token. According to the SET RFC <span>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.<br>
</span></p>
<p><span>Vladimir<br>
</span></p>
<pre cols="72">Vladimir Dzhuvinov</pre>
<div>On 29/03/2022 18:24, Vittorio Bertocci
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Vladimir!
<div>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).</div>
<div>What are the use cases where the extra info you are
embedding there leads to different processing logic?</div>
<div>thanks</div>
<div>V.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Mar 29, 2022 at 8:20
AM Vladimir Dzhuvinov via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<p><strong>This message originated outside your
organization.</strong></p>
<br>
<hr><br>
</div>
<p>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.<br>
</p>
<p>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).</p>
<pre><code>{
<span>"kid"</span> : <span>"1"</span>,
<span>"alg"</span> : <span>"RS256"</span>,
<span>"typ"</span> : <span>"id_token+jwt"</span>
}</code></pre>
<pre><code>{
<span>"kid"</span> : <span>"1"</span>,
<span>"alg"</span> : <span>"RS256"</span>,
<span>"typ"</span> : <span>"userinfo+jwt"</span>
}</code></pre>
<p><br>
</p>
<p>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.<br>
</p>
<p>Vladimir<br>
</p>
<pre cols="72">--
Vladimir Dzhuvinov</pre>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>