[Openid-specs-ab] sub vs subject identifier object

[Dick Hardt]

(changed subject line in case others want to discuss)

Hey Andrii -- would you open an issue on this if you still want to discuss.

/Dick

On Mon, Apr 21, 2025 at 9:37 PM Dick Hardt <dick.hardt at gmail.com> wrote:

> 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/20250428/bdced2f7/attachment.htm>