[Openid-specs-ab] Review of OpenID Provider Commands (draft 00)

[Dick Hardt]

On Wed, Mar 12, 2025 at 10:53 PM Andrii Deinega <andrii.deinega at gmail.com>
wrote:

> On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>
>> On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <andrii.deinega at gmail.com>
>> wrote:
>>
> <snip>


>>> 2. An OP should be able to encrypt OP Commands using encryption keys(s)
>>> when they are available in the Client's Metadata.
>>> <https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata>
>>>
>>
>> Why would that be useful? It might not be currently specified, but the
>> commands_uri MUST be HTTPS, so secrecy is provided between OP and RP.
>>
>
> These days, you typically don't get an end-to-end TLS session between the
> involved parties, there are all sorts of intermediaries that perform TLS
> offloading, deep packet inspection (DPI) and whatnot. But, I can also turn
> your question around - why does OpenID Connect Core spec allow encrypting
> its ID Tokens?
>

The core spec allows ID Tokens to be sent in the redirect (the implicit
flow) which makes them visible to anything that can monitor browser URLs
and could end up in server logs. That would be my guess on why it is in
OpenID Connect Core -- but I was not one of the authors.


>
>>
>>>
>>> 5. I suggest using the claim "member_of" instead of "group" in OP
>>> Commands such as the activate command.
>>>
>>
>> Why?
>>
>
> I'd say it's because of all my prior LDAP experience (specifically MS
> flavor of it), I'd love to hear other opinions from the WG.
>

groups is already a defined claim in IANA

I prefer groups -- but no strong opinion -- what do others think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250313/0ab13b58/attachment.htm>