<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">So I think there are a couple of things I’d like to add to this conversation.<div><br></div><div>1. The original intent/purpose of the id_token is to communicate an identity assertion to the requesting client about the logged in user. Hence the ‘aud’ claim in the id_token being the client_id of the requesting client. General JWT based ‘aud’ claim processing rules require another party receiving the id_token to reject it because the ‘aud’ claim doesn’t match the receiver (see section 4.1.3 of RFC 7519). I have significant concerns around trying to re-purpose the id_token for something different (communicating status of the authentication to another party than the requesting client).</div><div><br></div><div>2. The need for a secure way for the client to communicate to another party (e.g. resource server) status about the authenticated user is valid. However, I don’t believe that using the id_token is the best way to do this. That is because, in addition to the ‘aud’ claim issues highlighted previously, there are significant privacy risks in doing so. I’ve seen many deployments that put user claims into the id_token that are NOT appropriate for a subsequent resource server. Asking the AS to limit the user claims in the id_token because it will be used to communicate authentication status to a resource server could hamper the requesting client as it now needs a different way to get those user claims that are appropriate just for itself. I would much prefer that a new token be defined for the explicit purpose of communicating authentication status. That frees up the AS to limit PII related claims in that token while providing them in the id_token to the requesting client. This also allows the AS to identify the list of ‘aud’ values matching the receiving servers or potentially removing it completely.</div><div><br></div><div>3. A new ’scope’, as currently proposed, can instruct the AS to return this new token. There is much precedent for scopes to trigger this type of behavior including the ‘openid’ scope itself.</div><div><br></div><div>In my career I have rarely seen overloading intent to work out well. Maybe others have a different experience.</div><div><br></div><div>Thanks,</div><div>George</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br class="Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>On Sep 5, 2025, at 5:18 AM, Jacob Ideskog via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div>Hi all,</div><div><br></div><div>I'd like to chip in on the semantics of the two approaches.</div><div><br></div><div>The way I've always interpreted the id_token vs the user info is the following:</div><div><br></div><div>The <b>id_token</b>
represents the authentication transaction that just took place. For
that reason it contains important non-profile information such as
auth_time, acr, amr etc which are useful for the RP when deciding if the
authentication that took place is strong enough, fresh enough etc. It <i>can</i> also contain a number of useful claims about the account or the user but at a minimum it needs the subject in some form.</div><div><br></div><div>The <b>user info </b>on
the other hand is mainly governed by the profile scope and sibling
scopes. It does not contain authentication specific information but
rather only account specific details. </div><div><br></div><div>In our
implementation we tend to recommend adding account/user claims in the ID
token if you think the RP needs them to save them the round trip for
user info, but it's optional and up to the particular use-case. For
instance if you intend to share the ID token as this spec proposes, then
adding account claims should be weighed against the privacy posture
required.</div><div><br></div><div>That said, to me, issuing a proof
based on user info is less valuable to a 3rd party as it would not
contain the authentication specific details that may matter to that
party as well. If nothing else, the auth_time is generally valuable. It
could also convey details about how long the OP considers the session to
be valid for if you chose to interpret the exp as such.</div><div>Issuing
a bound ID token seems more to the point if that's the main
use-case we're after. If all we want to do is share user info details to
another party then a credential would do.</div><div><br></div><div>It sounds like they solve different problems and should not be mixed.</div><div><br></div><div>Just my 2¢</div><div><br></div><div>/Jacob Ideskog</div><div><br></div><br><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 21 Aug 2025 at 19:39, Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">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 dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Here is my homework as assigned by the working group chair. :)</div><div dir="ltr"><br></div><div>KB = OpenID Connect Key Binding</div><div>UVC = OpenID Connect UserInfo Verifiable Credentials</div><div>Links to specs at bottom</div><div><br></div><div><b>Tl;dr:<br></b>KB adds the key to an ID Token<br>UVC creates a verifiable credential with same info, but VC syntax</div><div>KB does it in one call to OP</div><div>UVC requires two calls to OP</div><div><br></div><div><b>Key Bound Token</b></div><div>KB outputs an id_token that includes a `cnf` claim of the public key</div><div>UVC outputs a verifiable credential with a `did:jwk:ey...` claim<br>Both include all the same user claims </div><div><br></div><div><br></div><div><b>Authentication Request</b></div><div>- KB uses `dpop` scope as well as `dpop_jkt` parameter</div><div>- UVC uses `userinfo_credential`</div><div dir="ltr"><br></div><div>KB has extra layer of security as `dpop_jkt` provides additional assurance between authentication request and token request</div><div><br><b>Token Request</b></div><div>- KB - RP passes DPoP JWT as header </div><div>- UVC has no changes</div><div><br></div><div><b>Token Response</b></div><div>- KB - OP passes back id_token that includes `cnf` claim</div><div>- UVC - OP passes back an access_token as well as c_nonce and c_nonce_expires_in</div><div><br></div><div>At this point, KB has completed the key binding ... </div><div><br></div><div><b>Credential Request and Response </b></div><div>UVC continues on <br></div><div>- RP generates a verifiable credential request and passes it with the access_token as a bearer token to the OP's credential endpoint </div><div>- OP returns a verifiable credential</div><div><br></div><div dir="ltr"><br><div><a href="https://dickhardt.github.io/openid-key-binding/main.html" target="_blank">https://dickhardt.github.io/openid-key-binding/main.html</a></div><div><a href="https://github.com/dickhardt/openid-key-binding" target="_blank">https://github.com/dickhardt/openid-key-binding</a></div><div><br></div><div><a href="https://openid.net/specs/openid-connect-userinfo-vc-1_0.html" target="_blank">https://openid.net/specs/openid-connect-userinfo-vc-1_0.html</a></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></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><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="font-size:small"></span>Jacob Ideskog<br><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>CTO<br></div><div>Curity<br></div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span><div>Sankt Göransgatan 66, Stockholm, Sweden<br>M: <a value="+46727255655" style="color:rgb(17,85,204)">+46 70-2233664</a><br><font style="color:rgb(17,85,204)" color="#009900"><a href="mailto:jacob@twobo.com" style="color:rgb(17,85,204)" target="_blank">j</a><a href="mailto:acob@curity.io" target="_blank">acob@curity.io</a></font></div></div><div><font style="color:rgb(17,85,204)" color="#009900"><a href="http://curity.io/" target="_blank">curity.io</a></font></div><div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>Openid-specs-ab mailing list<br>Openid-specs-ab@lists.openid.net<br>https://lists.openid.net/mailman/listinfo/openid-specs-ab<br></div></blockquote></div><br></div></body></html>