<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;"><div><br class="Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>On Sep 9, 2025, at 2:03 PM, Dick Hardt <dick.hardt@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr">> And then add new code for presentation of the id_token to RP2 using DPoP<br><br>why would this be DPoP?<br><br>This would be protocol specific between RP1 and RP2</div></div></div></blockquote><div><br></div>I guess I assumed that RP1 and RP2 would be code written by different companies and so having a standard to specify how the recipient (RP2) verifies the ‘cnf’ claim in the token would be helpful. Otherwise, if RP2 is a SaaS app, then it might have to implement many different proprietary mechanisms depending on the different RP1’s it was interacting with.</div><div><br><blockquote type="cite"><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Sep 9, 2025 at 6:49 PM <<a href="mailto:george@practicalidentity.com">george@practicalidentity.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><div><br></div>
</div>
<div><br><blockquote type="cite"><div>On Sep 9, 2025, at 12:54 PM, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">I agree there is potential for RP1 to share info it should not share with RP2 <br><br>It is unclear that the extra complexity of asking for a new token is going to prevent that any better than an OP deciding it won't issue an id_token with key binding. IE the OP making a decision about what is in an id_token and not in another token seems complicated for most OPs. <br><br></div></div></div></blockquote><div><br></div>Maybe I’m missing the complexity. If the spec defines the claims of the new token, then it can limit the privacy implications of the issued tokens (e.g. the token contains ’iss’, ’sub’, ‘amr’, …). It doesn’t have to include email address or other PII claims as the receiving entity just wants proof of the user’s authentication status. In fact you might not even need ’sub’ and could potentially use a ’session id’ instead. Though this probably depends on the deployment requirements.</div><div><br><blockquote type="cite"><div><div dir="ltr"><div dir="ltr">More importantly to me, I am concerned about the lift to educate implementers about a new token and a new way to ask for it. I suspect the lack of interest in the OpenID Connect UserInfo Verifiable Credentials is due to the complexity. <br></div></div></div></blockquote><div><br></div>Won’t we need to communicate to implementors a new scope to pass as part of the authentication request? And then add new code for presentation of the id_token to RP2 using DPoP? We also need to communicate to the OPs the special logic they need to consider based on the PII claims being issued into the id_token as to whether it should add the ‘cnf’ claim or not?</div><div><br></div><div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><br>I also don't think we are overloading the id_token -- but we can agree to differ in our opinion on that.<br></div></div></div></blockquote><span style="font-size:-webkit-xxx-large">👍 😀</span><br><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 9, 2025 at 1:51 PM <<a href="mailto:george@practicalidentity.com" target="_blank">george@practicalidentity.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>Hi Dick,<div><br></div><div>Thanks for answering my question (again) :)</div><div><br></div><div>I don’t feel like the argument of “the OP can’t prevent the RP from doing X” is a viable one for specifications. The spec should encourage/push/require the RP to “do the right thing”. I believe the current model makes is easy for the RP to “do the WRONG thing”. </div><div><br></div><div>Use cases where the id_token flows across trust boundaries make no sense. The ’sub’ claim, in many cases, has no relevance in the second trust domain as the identifier for the user is different (GUID in trust domain A does NOT equal the user in trust domain B). This is why the identity chaining spec leveraged the JSON Authorization Grant to allow the AS in trust domain A to correctly identify the user in trust domain B. </div><div><br></div><div>Also, trying to leverage user consent as a way to solve this is really a “user experience dark pattern”. What the user is trying to do will NOT work if they don’t consent. What if the RP requesting the id_token also needs to know some personal health information and wants that in the id_token. Now the user is sharing that data with whoever the RP decides? Or has to make the choice between sharing or reduced functionality? </div><div><br></div><div>I’m still confused why a dedicated token for authentication/status is not a viable option? If the RP is a web based RP, then requesting this token from the AS either during the authentication front channel flow, or via a backchannel flow like ID-JAG shouldn’t be an issue. For me, just because the RP is already getting the id_token doesn’t mean we should overload the id_token semantic.</div><div><br></div><div>Thanks,</div><div>George</div><div><br id="m_-7084260260914778808m_7221340386954408307lineBreakAtBeginningOfMessage"><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br>
</div>
<div><br><blockquote type="cite"><div>On Sep 9, 2025, at 1:16 AM, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi George<br><br>My answer to your question:<br><br><div><div style="width:1440px"><div><div><div><div><div><div><div><div id="m_-7084260260914778808m_7221340386954408307gmail-:3" style="height:746px"><div id="m_-7084260260914778808m_7221340386954408307gmail-:1" style="min-height:556px"><div><div role="main"><div><div><div><div><div role="list"><div role="listitem" aria-expanded="true"><div style="border-top-color:rgb(239,239,239);width:1096px"><div style="border-top:1px solid rgba(100,121,143,0.12)"><div id="m_-7084260260914778808m_7221340386954408307gmail-avWBGd-3025"><div id="m_-7084260260914778808m_7221340386954408307gmail-avWBGd-3026"><div><div><div><div id="m_-7084260260914778808m_7221340386954408307gmail-:6pm"><div id="m_-7084260260914778808m_7221340386954408307gmail-:6pl"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr">If RP1 requests claims that MUST NOT be sent to RP2, then what is the OP supposed to do? Reject the request? Send back an id_token that is insufficient for the client (RP1) but good for RP2? Send back an id_token that works for both the client and RP2 which has leaked privacy claims?</div></div></blockquote></div><div><div dir="ltr"><div><br>Is that the OP can't prevent RP1 from sending whatever it wants to RP2. If the OP does not trust RP1 to do the right thing, then perhaps the OP should not issue an id_token to RP1?</div><div><br></div><div>I have added the following content to the Privacy Considerations and added you to the acknowledgements: </div><div><br></div><div><div>> Public key bound ID Tokens will often contain personal (PII). The RP SHOULD obtain user consent before sharing a Public key bound ID Token that contains PII with a third party.</div></div></div></div><span></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 9, 2025 at 1:57 AM <<a href="mailto:george@practicalidentity.com" target="_blank">george@practicalidentity.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>Ok, let me restate. RP1 is an OpenID Connect Relying Party acting as an OAuth 2.0 client. This is exactly how OpenID Connect defines the Relying Party term.</div><div><br></div><div><dl style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small;font-variant-ligatures:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><dt>Relying Party (RP)</dt><dd>OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.</dd></dl></div><div>The point is not what RP1 can or cannot do with data it receives. Just because RP1 CAN send the id_token to another party doesn’t mean is SHOULD. The point is to define a mechanism that maximizes the likelihood RP1 will “do the right thing”. Which from what I understand, is that RP1 needs to communicate information about the authentication status/context with another entity. This information needs to be authorized by the OP and MUST NOT leak PII about the subject that the receiving entity should not receive.</div><div><br></div><div>Also, I didn’t see an answer to my question… </div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr">If RP1 requests claims that MUST NOT be sent to RP2, then what is the OP supposed to do? Reject the request? Send back an id_token that is insufficient for the client (RP1) but good for RP2? Send back an id_token that works for both the client and RP2 which has leaked privacy claims?</div></div></blockquote></div><br id="m_-7084260260914778808m_7221340386954408307m_5231639970417832905lineBreakAtBeginningOfMessage"><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br>
</div>
<div><br><blockquote type="cite"><div>On Sep 8, 2025, at 7:27 AM, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">> Finally, to Dick’s points about RP1 (really the OAuth client) sending it to RP2, I believe that creates a mutually exclusive decision for the OP. If the client requests claims that MUST NOT be sent to RP2, then what is the OP supposed to do? Reject the request? Send back an id_token that is insufficient for the client (RP1) but good for RP2? Send back an id_token that works for both the client and RP2 which has leaked privacy claims?<br><br>RP1 is not an OAuth client -- it is an RP. It does not want authorization, it wants authentication. The OP cannot prevent RP1 from sending any information it wants to RP2 independent of it being in an id_token or in another part of the communication -- what RP1 shares with RP2 is going to be based on business decisions, not a technical barrier of it not being in an id_token. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 8, 2025 at 12:17 PM <<a href="mailto:george@practicalidentity.com" target="_blank">george@practicalidentity.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>I’m going to respond to a couple points from different emails here as it’s easier to do it in one post :)<div><br></div><div>Dick asked why I didn’t object to ID-JAG as the ‘aud’ rule isn’t applied by the OP in that draft.</div><div><br></div><div>For me, the reason is that back when we did OpenID Connect Core, there was the issue of the id_token_hint parameter which meant sending the id_token back to the issuer that issued it. We had the discussion at that time and the way I remember it, we all agreed that it was ok for the id_token to be sent back to its issuing OP. I believe Karl makes the same point. I don’t see any privacy risks here either as the OP put all the claims into the id_token.</div><div><br></div><div>Now regarding the comment about the Native SSO spec, in that spec also, the id_token is ONLY sent to the OP that issued it. Sending the id_token to a different OP would be outside the intent of that spec. As for clients written by the same company sharing the id_token, you could say that is an abuse of the ’aud’ rules and in fact there has been push back against the Native SSO spec for it’s use of the id_token.</div><div><br></div><div>Regarding the Kubctl use of the id_token, I worked with my colleague at Capital One to get this changed to using a JWT based access token as the purpose of the token in the K8 use case was for authorization NOT authentication context.</div><div><br></div><div>Finally, to Dick’s points about RP1 (really the OAuth client) sending it to RP2, I believe that creates a mutually exclusive decision for the OP. If the client requests claims that MUST NOT be sent to RP2, then what is the OP supposed to do? Reject the request? Send back an id_token that is insufficient for the client (RP1) but good for RP2? Send back an id_token that works for both the client and RP2 which has leaked privacy claims?</div><div><br></div><div>I still believe the best path forward is a dedicated token for this purpose. The ID-JAG model is fine, send the id_token back to the OP to request an authentication assertion for RP2 and get back the token to share. If there is concern that the OP then knows who the client is communicating with, then make the authentication assertion usable for everyone (though I daresay many enterprise IDPs would not want this feature).</div><div><br></div><div>Future responses today will be limited. I’ll check back this evening or tomorrow morning :)</div><div><br></div><div><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br>
</div>
<div><br><blockquote type="cite"><div>On Sep 7, 2025, at 5:07 PM, Karl McGuinness <<a href="mailto:me@karlmcguinness.com" target="_blank">me@karlmcguinness.com</a>> wrote:</div><br><div><div dir="ltr"><div>There are several widely deployed infrastructure use cases that already take an id_token as a bootstrap credential </div><div><ul><li><a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens" target="_blank">https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens</a></li><li><a href="https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html" target="_blank">https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html</a></li><li><a href="https://cloud.google.com/iam/docs/workload-identity-federation-with-other-providers" target="_blank">https://cloud.google.com/iam/docs/workload-identity-federation-with-other-providers</a></li></ul></div><div>It's common for a CLI tool for example to to use something like device authorization grant to obtain an id_token from an enterprise IdP end exchange the the id_token for a backend session with a control plane. In fact Okta uses OpenID Native SSO <a href="https://openid.net/specs/openid-connect-native-sso-1_0.html" target="_blank">https://openid.net/specs/openid-connect-native-sso-1_0.html</a> for its AWS CLI implementation to SSO to different AWS Accounts. These use cases are attempting to use the ID Token similar to a X.509 as would benefit from a key binding for an ID Token IMHO. From a deployment perspective it's so much easier to get an ID Token from an Enterprise IdP than an X.509 for these scenarios. The security benefits of supporting dynamic issued credentials from an IdP that can implement zero-trust security controls including MFA outweighs the privacy risks. </div><div><br></div><div>There are also cross-client identity scenarios <a href="https://developers.google.com/identity/protocols/oauth2/cross-client-identity" target="_blank">https://developers.google.com/identity/protocols/oauth2/cross-client-identity</a> where a native app for example may have its own identity and the backend a different client identity but to the end-user they are the same client. These deployments are a single trust domain and don't have the same privacy risks as cross-domain deployments</div><div><br></div><div>With ID-JAG the id_token issuer is the processor of the token exchange request. The assertion is something it issued so there wasn't a concern for the same party to also validate it. We didn't want the IdP to have to maintain the state with a refresh token so decided to use the serialized authentication context in the id_token for the request as the goal was a chained authentication. There is also interest to flow these claims also in the ID-JAG to downstream AS. I could see ID-JAG also supporting a key binding for the id_token if supported by the IdP. </div><div><br></div><div>-Karl</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 7, 2025 at 10:19 AM Dick Hardt 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 dir="ltr"><div dir="ltr">Hey George<br><br>I see you (and many others) were supportive for adoption of the Identity Assertion Authorization Grant </div><div dir="ltr"><br><a href="https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/" target="_blank">https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/</a><br><br>Where a client presents the id_token back to the OP/AS to get an ID-JAG token. Clearly the "aud" in the id_token is not the OP / AS. If presenting a token to a party that is not the "aud" is problematic, why did you not push back on that proposal? The AS could return a special token that the client could present back later to the OP to get an ID-JAG according to your logic below.<br><br>I think some of the difference of opinion here is evident in how you are describing what is happening. You are using the terms client and AS for the parties, which are OAuth / authorization terms -- and suggesting the id_token is being presented to an RS. <br><br>I would agree that using the id_token for authorization is problematic -- but that is not what we are proposing.<br><br>The RP1 gets an id_token that has a bound key from the OP. </div><div dir="ltr"><br></div><div dir="ltr">RP1 then presents the id_token to RP2, with some proof of possession mechanism specific to the RP1 -> RP2 protocol. <br><br>All the claims in the id_token are expected to be relevant in the presentation to RP2. <br><br>As Jacob notes -- the "auth_time", "acr", and "amr" claims could be very useful to RP2. <br><br>In other words, RP1 -> RP2 is a chained authentication event.</div><div dir="ltr"><br></div><div>/Dick<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 6, 2025 at 4:02 PM <<a href="mailto:george@practicalidentity.com" target="_blank">george@practicalidentity.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>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="m_-7084260260914778808m_7221340386954408307m_5231639970417832905m_2354752400882794883m_6745606554415311059m_-4491539738387885405m_4214007151636970833m_-5454414378634092052m_-5470901410087924560lineBreakAtBeginningOfMessage"><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br>
</div>
<div><br><blockquote type="cite"><div>On Sep 5, 2025, at 5:18 AM, Jacob Ideskog via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</div><br><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"><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" 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 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><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" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></blockquote></div><br></div></div></blockquote></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></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></blockquote></div>
</div></blockquote></div><br></body></html>