[Openid-specs-ab] Contributing OpenID Connect Relying Party Metadata Choices 1.0 spec to the working group

Thu Oct 10 09:53:10 UTC 2024

Yes, we definitely don't want the OP to return multiple-choices. This 
spec should not be used in responses from OPs.

Vladimir Dzhuvinov

On 09/10/2024 23:23, Michael Jones wrote:
>
> Filip’s observation that OPs wouldn’t return multiple choices in 
> Dynamic Client Registration responses is correct.  We can clarify that 
> in a subsequent version of the spec.
>
> -- Mike
>
> *From:*Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On 
> Behalf Of *Vladimir Dzhuvinov / Connect2id via Openid-specs-ab
> *Sent:* Wednesday, October 9, 2024 12:45 PM
> *To:* openid-specs-ab at lists.openid.net
> *Cc:* Vladimir Dzhuvinov / Connect2id <vladimir at connect2id.com>
> *Subject:* Re: [Openid-specs-ab] Contributing OpenID Connect Relying 
> Party Metadata Choices 1.0 spec to the working group
>
> This spec is intended for clients that need to publish their metadata, 
> for example at a well-known endpoint, without having a particular AS / 
> OP in mind.
>
> This is the natural situation in OpenID Federation. Federated RPs are 
> able to get auto-registered by many OPs, potentially OPs that belong 
> to more than one federation and are thus required to fulfill disjoint 
> policies / profiles.
>
> For example:
>
>   * Federation A allows ID tokens signed with RS256 and the majority
>     of its OPs support only that alg
>   * Federation B is FAPI 2.0 compliant and requires ID tokens signed
>     with other algs
>
> In OpenID Federation this spec also makes it possible to define and 
> apply RP metadata policies that are guaranteed to work across multiple 
> federations.
>
> Vladimir
>
> On 09/10/2024 20:40, Filip Skokan via Openid-specs-ab wrote:
>
>     Hello Mike,
>
>     I struggle to see these as metadata that the AS is meant to
>     respond with to a DCR request.
>
>     I understand the intention of allowing the client to say "here's
>     what I support, you choose for me". What I don't get is why the
>     client can't figure out what to use exactly based on the AS
>     metadata in the first place. I must be surely missing something so
>     apologies there.
>
>     Nevertheless I don't think the AS should ever have the need to
>     respond with these metadata in a DCR enpoint response. So, they
>     might be useful as input but don't make much sense in responses to me.
>
>     - Filip
>
>
>
>         9. 10. 2024 v 4:35, Michael Jones via Openid-specs-ab
>         <openid-specs-ab at lists.openid.net>
>         <mailto:openid-specs-ab at lists.openid.net>:
>
>         
>
>         The authors of the attached specification hereby contribute it
>         to the OpenID Connect working group.  It was created to
>         address issues
>         https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp
>         and https://github.com/openid/federation/issues/12.
>
>         -- Mike
>
>         *From:*Michael Jones
>         *Sent:* Thursday, October 3, 2024 10:09 PM
>         *To:* openid-specs-ab at lists.openid.net
>         *Subject:* FW: OpenID Connect Relying Party Metadata Choices
>         1.0 spec
>
>         On Monday’s working group call, we discussed that I should go
>         through the list of registered OAuth Client Metadata values
>         <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata>
>         and see if there were any more that should be added to the
>         list in this specification.  My conclusion was that there were
>         not.  I’ll therefore plan to contribute it to the working
>         group as-is so we can start addressing the issues filed unless
>         I hear feedback soon requesting changes first.
>
>         Thanks all,
>
>         -- Mike
>
>         *From:*Michael Jones
>         *Sent:* Sunday, September 29, 2024 7:53 PM
>         *To:* openid-specs-ab at lists.openid.net
>         *Subject:* OpenID Connect Relying Party Metadata Choices 1.0 spec
>
>         The attached spec (with source and HTML output) defines client
>         metadata parameters corresponding to all the single-valued
>         OpenID Connect Dynamic Client Registration metadata
>         parameters, letting RPs declare the sets of values for these
>         parameters that they support.  This is intended to address
>         both
>         https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp
>         and https://github.com/openid/federation/issues/12.
>
>         Reviews welcomed!
>
>         -- Mike
>
>         <openid-connect-rp-metadata-choices-1_0.xml>
>
>         <openid-connect-rp-metadata-choices-1_0.html>
>
>         _______________________________________________
>         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/20241010/3a6b6d3a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20241010/3a6b6d3a/attachment-0001.p7s>