<div dir="ltr">Hi George,<div><br></div><div>They are related in the fact that they share the same set of identity claims about a user & signed by the same issuer.  A developer for example who implemented JIT provisioning with an ID Token would process the same claims in a "maintain" command token and validate the token using the same trust root & signing keys.  In other words, the Claim Registration for ID Tokens is reused for Command Tokens.</div><div><br></div><div>The RP discovers what claims an OP could issue for a user that could be sent via an ID Token or Command Token.   The idea is that the OP only publishes 1 view of the user to the RP.  A developer doesn't need to handle schema/mappings/etc differently if they get the claims via UserInfo, and ID token, or a Command Token it's all the same OP identity for the RP</div><div><br></div><div>-Karl</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Mar 14, 2025 at 7:53 AM george--- 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">Hi Joseph,<br>
<br>
I agree. My point was more that OP Commands should NOT try and relate itself to id_tokens at all. Instead, define the OP Command JWT using current best practice and then make the point that the keys used to sign the OP Command are the same as those used to sign an ID Token. Otherwise, I’m not sure there need to be any mention of ID Tokens at in the context of OP Commands.<br>
<br>
George Fletcher<br>
Identity Standards Architect<br>
Practical Identity LLC<br>
<br>
<br>
<br>
> On Mar 13, 2025, at 8:46 PM, Joseph Heenan <<a href="mailto:joseph@authlete.com" target="_blank">joseph@authlete.com</a>> wrote:<br>
> <br>
> Hi George<br>
> <br>
> As others said, the OP Commands is required to be explicitly typed, at least in the current draft.<br>
> <br>
> However explicitly typing the OP Command is not sufficient to avoid confusion attacks with an id_token, as checking typ is not part of the id_token processing rules in Connect Core.<br>
> <br>
> Thanks<br>
> <br>
> Joseph<br>
> <br>
> <br>
>> On 14 Mar 2025, at 01:57, george--- via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>> <br>
>> Hi,<br>
>> <br>
>> As part of OP Commands, a design goal is to re-use the signing mechanisms of the id_tokens in the ecosystem (at least that is my understanding). In looking at the OpenID Connect core spec, it’s not very clear what should be present in the JWT Header object of a signed (JWS) id_token. The examples in the appendix include the ‘kid’ and ‘alg’ claims. <br>
>> <br>
>> I’m wondering if it’s possible for the OP Command to be an explicitly typed JWT to make it very clear it is NOT an id_token (rather than relying on presence or absence of a nonce claim) and still use the same keys for signing. It seems to me that the keys used for signing are not in any way bound to only being used for id_tokens and hence could be used for other JWT based structures.<br>
>> <br>
>> That might make some of this simpler and allow OP Commands to be extended in a cleaner way than trying to maintain some compatibility to id_tokens.<br>
>> <br>
>> Thoughts?<br>
>> <br>
>> George Fletcher<br>
>> Identity Standards Architect<br>
>> Practical Identity LLC<br>
>> <br>
>> <br>
>> <br>
>> _______________________________________________<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>
> <br>
<br>
_______________________________________________<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>