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

[Andrii Deinega]

Hi Dick, I've submitted
https://github.com/openid/openid-provider-commands/issues/17 for that.

All the best,
Andrii

On Mon, Apr 28, 2025 at 8:50 PM Dick Hardt <dick.hardt at gmail.com> wrote:

> (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/c12c949e/attachment.htm>