[Openid-specs-ab] security implications of client_id or endpoint as "aud" in OpenID Provider Commands

[Dick Hardt]

Ambiguous does not seem like a good goal. Why would we want that Andrii?

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.

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.

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.

On Mon, Apr 21, 2025 at 8:34 PM Andrii Deinega via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> I'm glad we're having this discussion, and yes, I support this change.
>
> I also propose another important change to keep things ambiguous, this
> change moves the spec from the "plain" sub claim to subject identifiers (RFC
> 9493 <https://datatracker.ietf.org/doc/rfc9493>) for all OP Commands and
> audit events.
>
> 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).
>
> All the best,
> Andrii
>
>
> On Sun, Apr 20, 2025 at 6:03 PM Nat Sakimura via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> I am also in favour of having "aud" value to be the command_endpoint URL.
>> That goes with BCM principles, per of ISO/IEC 9798 (David Basin, Cas
>> Cremers, and and Simon
>> Meier )
>>
>> Basin, D., Cremers, C., Meier, S. (2913). *Provably Repairing the
>> ISO/IEC 9798 Standard for Entity Authentication. Journal of Computer
>> Security - *Security and Trust Principles archive Volume 21 Issue 6,
>> 817-846 (2013) <
>> https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-
>> iso9798.pdf>
>> State why it has to be like that and for a good reason. We should comply
>> to it.
>>
>> Best
>>
>> Nat
>>
>>
>>
>> 2025年4月19日(土) 4:32 george--- via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net>:
>>
>>> 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.
>>>
>>> Thanks,
>>> George
>>>
>>> --
>>> George Fletcher
>>> Practical Identity LLC
>>>
>>> On Apr 17, 2025, at 10:49 AM, Dick Hardt via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>> 
>>> Hello!
>>>
>>> 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.
>>>
>>> We want to ensure that a command token is not confused with an id token.
>>>
>>> Currently the spec has the same "aud" value in the command token as an
>>> id token -- the client_id value.
>>>
>>> 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.
>>>
>>> https://github.com/openid/openid-provider-commands
>>>
>>> https://github.com/openid/openid-provider-commands/issues/4
>>>
>>> Thanks in advance for your feedback and review!
>>>
>>> /Dick
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250421/edff70f4/attachment-0001.htm>