<div dir="ltr"><div>(changed subject line in case others want to discuss)<br><br>Hey Andrii -- would you open an issue on this if you still want to discuss.</div><div><br></div><div>/Dick</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Apr 21, 2025 at 9:37 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.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 dir="ltr">Ambiguous does not seem like a good goal. Why would we want that Andrii?<div><br></div><div>While using subject identifiers would align OP Commands with SETs and Shared Signals -- I don't think that is a step in the right direction. <br><br>I think it is much more valuable to have a command_token use identity claim syntax for the subject that mirrors an id_token. Moving the Client Identifier to client_id and aud be the command_endpoint differentiates a command token from an id token, and is used in the verification step -- but allowing the subject identifier to be any of a number of syntaxes and hence semantics other than a sub would lead to confusion at the RP. <br><br>OP Commands should be scoped to RPs using OpenID Connect. Being a general purpose command mechanism I believe is significant scope creep that will make it more complicated. The subject identifier is a core concept that should align with ID Tokens and optionality does not provide any value to an RP.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 21, 2025 at 8:34 PM Andrii Deinega 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">I'm glad we're having this discussion, and yes, I support this change.<div><br></div><div>I also propose another important change to keep things ambiguous, this change moves the spec from the "plain" sub claim to subject identifiers (<a href="https://datatracker.ietf.org/doc/rfc9493" target="_blank">RFC 9493</a>) for all OP Commands and audit events.</div><div><br></div><div>The metadata on both sides can be extended with an array of the supported identifiers (say sub_id_formats_supported). That would let both parties negotiate and clearly identify what exactly they’re dealing with (if it's an opaque identifier, an email address and so forth).</div><div><br></div><div>All the best,</div><div>Andrii</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 20, 2025 at 6:03 PM Nat Sakimura 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="auto"><div dir="ltr">I am also in favour of having "aud" value to be the command_endpoint URL. <div>That goes with BCM principles, per of ISO/IEC 9798 (David Basin, Cas Cremers, and and Simon</div>Meier ) <div><br></div><div>Basin, D., Cremers, C., Meier, S. (2913). <i>Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication. Journal of Computer Security - </i>Security and Trust Principles archive Volume 21 Issue 6, 817-846 (2013) <<a href="https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-" rel="noreferrer" target="_blank">https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-</a><br>iso9798.pdf> </div><div>State why it has to be like that and for a good reason. We should comply to it. </div><div><br></div><div>Best</div><div><br></div><div>Nat</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2025年4月19日(土) 4:32 george--- via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-ab@lists.openid.net</a>>:<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="auto">I’m in favor of this proposal. I didn’t see anyone else respond on the list. I’m assuming that is the command_endpoint_url of the relying party and not the IDP.<div><br></div><div>Thanks,</div><div>George</div><div><br id="m_-6847375445308189206m_5822650721058561132m_-277586402896887244m_-3212010126734746434m_5511772252312366323lineBreakAtBeginningOfSignature"><div dir="ltr">--<div>George Fletcher</div><div>Practical Identity LLC</div></div><div dir="ltr"><br><blockquote type="cite">On Apr 17, 2025, at 10:49 AM, Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hello!<br><br>We are working on a new specification, OpenID Provider Commands.The commands are a JWT that is similar to an ID Token that have the same "iss" and same verification, and share identity claims. The OP sends command tokens to an RP.<br><br>We want to ensure that a command token is not confused with an id token. <br> <br>Currently the spec has the same "aud" value in the command token as an id token -- the client_id value. <br><br>We are considering setting the "aud" value to be the command_endpoint URL and to set the "client_id" claim to be the client_id value.<br><br><a href="https://github.com/openid/openid-provider-commands" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands</a><br><br><a href="https://github.com/openid/openid-provider-commands/issues/4" rel="noreferrer" target="_blank">https://github.com/openid/openid-provider-commands/issues/4</a><br><br>Thanks in advance for your feedback and review!<br><br>/Dick</div></div></div></div></div>
<span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a></span><br><span><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></span><br></div></blockquote></div></div>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></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>
_______________________________________________<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>
</blockquote></div></div>