<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I agree this is a good and sensible approach. I like the rework
argument, as a mean to nudge people in the right direction :)<br>
</p>
<p>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).<br>
</p>
<pre class="moz-signature" cols="72">Vladimir Dzhuvinov</pre>
<div class="moz-cite-prefix">On 29/03/2022 19:38, Vittorio Bertocci
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEFJvaq3wVZ8=ZAadwEFT8eDG-1aNWvAbmnBoRtBrFgxH7-aEw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>