<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;">Hi,<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thoughts?</div><div><br></div><div><div>
<div>George Fletcher</div><div>Identity Standards Architect</div><div>Practical Identity LLC</div><div><br></div><br class="Apple-interchange-newline">
</div>
<br></div></body></html>