solid-oidc
solid-oidc copied to clipboard
solid
Reconsider Client Identifiers in light of OpenID Federation Entities
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 https://github.com/solid/solid-oidc/issues/207#issuecomment-1301065781):
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
In https://github.com/solid/specification/issues/463#issuecomment-1300857441 @woutermont suggests
We can thus perfectly envision an app with WebID / Entity Identifier / ClientID
https://example.app, serving an RDF description on its base URL and a JSON Entity Configuration onhttps://example.app/.well-known/openid-federation.
I could start a draft PR to the primer which starts moving it in this direction.
Great! Very much looking forward to implementing this. If I can be of any help drafting/editing/reviewing, let me know!
not sure why is would be an RDF description and not an entity statement as defined in OpenID Federation specification?
+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
[@Sakurann:] not sure why is would be an RDF description and not an entity statement as defined in OpenID Federation specification?
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-federation is 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 a 303 to the WebID Document https://ex.app/profile and serving its Entity Configuration on https://ex.app/.well-known/openid-federation.
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
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-federation is required.
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."
@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-federation in order to fetch ..." That base URL itself can still serve whatever it wants.
@selfissued could you please help us clarify if there would be any problem with following
- Entity Identifier -
https://app.example - Entity Configuration -
https://app.example/.well-known/openid-federation
Where resolving the entity identifier can be anything, for example 303 redirect with content negotiation
Where resolving the entity configuration follows
The response is an Entity Configuration, as described in Section 3.1. If the Entity is an intermediate Entity or a Trust Anchor, the response MUST contain metadata for a federation Entity.
An Entity Statement contains the information needed for the Entity that is the subject of the Entity Statement to participate in federation(s). An Entity Statement is always a signed JWT. The subject of the JWT is the Entity itself. The issuer of the JWT is the party that issued the Entity Statement. All Entities in a federation SHOULD be prepared to publish an Entity Statement about themselves (Entity Configuration).
Entity Statement JWTs MUST be explicitly typed, by setting the typ header parameter to entity-statement+jwt. This is done to prevent cross-JWT confusion (see [RFC8725], section 3.11).
Thank you for bringing this to our attention, @acoburn. This would indeed solve the issue described in https://github.com/solid/specification/issues/463 !
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-federation when using automatic registration.
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
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.