Repository navigation
Reconsider Client Identifiers in light of OpenID Federation Entities #207
Description
This issue brings in several related issues, including #199, #95, #202 and #201, reframing the issue as the following:
The Solid-OIDC specification currently makes use of globally unique client_id values, formatted as URLs that dereference to a Client Identifier Document (as defined by Solid-OIDC). A very similar mechanism is defined by the (draft) OpenID Connect Federation specification.
This issue is here to discuss the proposal (edited to incorporate #207 (comment)):
The Solid-OIDC specification should drop the current definition of Client Identifiers and associated JSON-LD appendix in favor of adopting the OpenID Connect Federation definition of an Entity Identifier and Automatic Registration
/cc @Sakurann
Activity
elf-pavlik commentedon Nov 2, 2022
We probably should also reference 10.1. Automatic Registration
elf-pavlik commentedon Nov 2, 2022
In solid/specification#463 (comment) @woutermont suggests
I could start a draft PR to the primer which starts moving it in this direction.
woutermont commentedon Nov 2, 2022
Great! Very much looking forward to implementing this. If I can be of any help drafting/editing/reviewing, let me know!
Sakurann commentedon Nov 2, 2022
not sure why is would be an RDF description and not an entity statement as defined in OpenID Federation specification?
Sakurann commentedon Nov 2, 2022
+1 to "adopting the OpenID Connect Federation definition of an Entity Identifier and Automatic Registration.
I think it is one of the best approaches out there right now that meets the new requirements of issuer-holder-verifier model ecosystem, where wallets managing client_id per issuer/AS becomes unrealistic - it is an approach with a significant standardization effort having put in, with implementations on-going and a good trust checking mechanism in place.
One caveat being that most of the existing Authorization Servers do not support Bring Your Own Cliend_id model
woutermont commentedon Nov 3, 2022
The OpenID Federation does not specify what must be served on dereferencing the Entity Identifier (ClientID) itself; only the Entity Configuration (i.e. self-issued Entity Statement) at
/.well-known/openid-federationis required. This leaves us the freedom to let the Entity Identifier (ClientID) itself dereference to an RDF description of the Entity, e.g. a WebID Document.We can then have, for example: an App
https://ex.app, dereferencing with a303to the WebID Documenthttps://ex.app/profileand serving its Entity Configuration onhttps://ex.app/.well-known/openid-federation.acoburn commentedon Nov 3, 2022
For those who may not follow the gitter channel, the Solid Authentication panel plans to hold a meeting to discuss this issue on Monday 7 Nov at 14:00 UTC
selfissued commentedon Nov 4, 2022
This is not the case. Per https://openid.net/specs/openid-connect-federation-1_0-24.html#name-automatic-registration "In all interactions with the OP, the RP employs its Entity Identifier as the Client ID. The Entity Identifier is the URL from which the OP can fetch the RP's Entity Configuration using the process described in Section 6."
woutermont commentedon Nov 4, 2022
@selfissued, nothing in that sentence, or in Section 6 refutes my statement. To the contrary: that section explains that the phrasing "from which the OP can fetch ..." must be understood as "which the OP can use as base URL to combine with
/.well-known/openid-federationin order to fetch ..." That base URL itself can still serve whatever it wants.elf-pavlik commentedon Nov 5, 2022
@selfissued could you please help us clarify if there would be any problem with following
https://app.examplehttps://app.example/.well-known/openid-federationWhere resolving the entity identifier can be anything, for example 303 redirect with content negotiation
Where resolving the entity configuration follows
tomhgmns commentedon Nov 8, 2022
Thank you for bringing this to our attention, @acoburn. This would indeed solve the issue described in solid/specification#463 !
selfissued commentedon Nov 9, 2022
Thanks for the useful discussion. I've filed this issue https://bitbucket.org/openid/connect/issues/1716/clarify-that-entity-statement-paths to clarify that Entity Statements are retrieved from a path that concatenates the Entity Identifier with
/.well-known/openid-federationwhen using automatic registration.elf-pavlik commentedon Nov 14, 2022
Last week we decided to pursuit this direction. This week I'm going to submit a draft PR to the primer to see if we have all the details needed to showcase how a concrete example will work. Once we iron out any problems possibly encountered in that exercise, we can follow up with matching PR to the spec.
@selfissued Thank you for raising that issue. I've noted it being resolved in https://bitbucket.org/openid/connect/pull-requests/357
elf-pavlik commentedon Nov 21, 2022
I created very minimal draft PR #208, with intention to collaborate on it throughout this week and preferably meet next Monday to discuss outcome and next steps.