You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the Client does not use an identifier that can be dereferenced, then it MUST present a client identifier registered with the OP [Server] via either OIDC dynamic or static registration.
I always interpreted as a compatibility clause, enabling Clients that already have a non-URL ClientID with certain OPs to still use that ID, and allowing (semi-)closed systems using a limited set of statically registered clients to still be Solid-compliant. However, in conversation with @ThisIsMissEm, the following ambiguity came up.
While the statement itself is about the Client identifying itself during the authentication request to the OP, it might also seem to hint at a requirement on the Server during an earlier registration request. After all, if a Client MUST present a ClientID obtained through static or dynamic registration, one would think that there MUST be a way to obtain said ClientID, and thus that the Server MUST provide static and/or dynamic client registration.
Whichever interpretation is the correct one, I suggest we clarify that in the specification.
The text was updated successfully, but these errors were encountered:
Yeah, specifically, there's no information that says that dynamic client registration is prohibited by a server, and only pre-registered clients can be used. (which appears to maybe be what use.id does in some instances, I can't tell fully by the 10 minutes I've spent investigating)
For clarity: use.id is an open platform, every app (customer or not) should be able to let a person login and access someones data when it has permissions.
The Solid-OIDC specification contains a section on OIDC Registration:
I always interpreted as a compatibility clause, enabling Clients that already have a non-URL ClientID with certain OPs to still use that ID, and allowing (semi-)closed systems using a limited set of statically registered clients to still be Solid-compliant. However, in conversation with @ThisIsMissEm, the following ambiguity came up.
While the statement itself is about the Client identifying itself during the authentication request to the OP, it might also seem to hint at a requirement on the Server during an earlier registration request. After all, if a Client MUST present a ClientID obtained through static or dynamic registration, one would think that there MUST be a way to obtain said ClientID, and thus that the Server MUST provide static and/or dynamic client registration.
Whichever interpretation is the correct one, I suggest we clarify that in the specification.
The text was updated successfully, but these errors were encountered: