specification: Inconsistency in identifiers for apps: WebIDs and ClientIDs
An app in Solid needs to have an identifier. The spec states that “WebIDs […] are used as the primary identifier for users and applications.” (Solid Protocol, Section 9.1).
However, currently, apps are not only identified by their WebID, but also by their ClientID.
This leads to inconsistencies that hinder implementation. Examples are:
- The Interop spec defines an endpoint for Agent Registration Discovery (Solid Interop, Section 7.1.2) that should be able to lookup a registration for an agent based on the user’s access token. This token contains the ClientID of the agent whilst the registries of the interop spec contain the WebID of the application
- There are two documents that describe an app (i.e. the WebID document and the ClientID document) and those documents contain duplicate information that is defined by different terms (e.g. interop:applicationName and oidc:clientName).
- …
Considering that the Solid spec states that WebIDs “should be the primary identifier for users and applications”, it seems logical to continue with the WebID of an app and drop the ClientID of an app.
One solution would be to merge the information in both documents into one (WebID) document and serialise this information as desired using content negotiation.
However, in this solution, there would be a number of additional problems:
- Solid and in particular Solid OIDC and the WebID spec say nothing about
Acceptheaders - This would still not solve the issue of different terms to describe the same information
Given the importance of keeping the specification consistent and the use of identifiers within Solid, I hope we can tackle this issue as fast as possible.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 2
- Comments: 36 (24 by maintainers)
Leading up to 0.9, we operated with milestones and project boards and a process to nominate and get issues on the board. Since I left Inrupt, I have not had the capacity to be a driving force for keeping the process going, but I believe we need to have that kind of structure and probably stick more closely to it too. At least, we can tag it.
Scope, in the sense not just of identifier string scope. But about scope of applicability, and satisfaction of criteria for entire setup ( deref + hosting config + …).
One single setup as per above can seemlessly satisfy entire scope of webid. We can use that wherever webid is expected. But it is not the case for usage as oidc-entity uri. For that setup is bound to / scoped to one single federation with single config.
There can be many work-arounds as specified above. The ideal case of having unique webid, and offering services in many federations with custom configurations is not possible, with webid also being entity-id.
Ideally one should certainly be able to maintain single webid, to identify across whole spectrum of it’s applicability. For users may want to say something about the app in federation agnostic way (review/ rate). It may be branding, accountability, etc…
In light of solid/solid-oidc#207, To have same identifier as openweb identifier (web-id), and oidc-identiier, following impedance mismatch between their semantics must be resolved. OIDC-federation can indeed seems allow us to do that.
Control of the identifier: Who mints, controls the identifier, and who can invalidate it. In classic OIDC, provider doesn’t allow
bring your own client_idmodel for identifier string. And entirely controls lifeycle of it, which is directly incompatible with webid semantics. OIDC-Federation entity identifiers seems allow thebring-your-ownmodel. Thus following case can workout.well-knownsuffixed uriScope of the identifier: WebId is globally unique for an app. Where as client-id need not be. As one app may want to be client of multiple providers (/ entity in multiple federations), with distinct configuration for each. In above mapping, it is only possibble to have single oidc-federation config for an app if entity-id is same as webid for every provider(/ in every federation). Thus this limitation have to be worked around, or accepted.
I agree. I just quickly grasped for those terms. But yes, something like
solid:Appandoidc:Clientwould have been better terms to use. Here<#app>is the WebID - in relative form, as we assume that the context in which it is dereferenced will resolve it to a full absolute URL. It is a WebID because it identifies an agent, but we can be more precise about what subtype of agent it identifies.Do we have official terms for any of those types yet?
Ok, I think I understood you @woutermont , I was just trying to make sure above to exclude the more bizzare interpretation.
Perhaps can put it logically too. Let us say that we have a
oidc:AppIdand a:ClientWebID. You are claiming these overlap or may even be identical concepts, thought to be distinct only for reasons of syntax of the documents. Ie that we can have<#app>be a WebID, that is both those subtypes simultaneously.That actually seems quite reasonable to me, and indeed it was considered by @acoburn quite early on, since he was arguing to allow WebIDs to have turtle representations for just that reason https://github.com/w3c/WebID/issues/3 .
Anyhow, if we would decide against to use one identifier for an app, it would help if we could include a reference to the other in each of the documents.
By that I mean that:
By doing this, we would know, for example, based on the WebID of an app, which redirect URIs are permitted.
That’s a problem indeed (related to #454).
I just created #465 to tackle this specific problem.
To keep specs orthogonal, I think this should remain this way. As long as they say that RDF MUST be returned, any standard RDF serialization should do. This will also avoid the problem of every (Solid) spec having to repeat statements about RDF serializations, which may end up conflicting.
See also this long thread on mandatory versus recommended RDF serializations in the WebID CG: https://github.com/w3c/WebID/issues/3