[Openid-specs-ab] security implications of client_id or endpoint as "aud" in OpenID Provider Commands
Andrii Deinega
andrii.deinega at gmail.com
Tue Apr 22 03:34:09 UTC 2025
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250421/9a6c3fee/attachment.htm>
More information about the Openid-specs-ab
mailing list