Inconsistency in identifiers for apps: WebIDs and ClientIDs

[tomhgmns]

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 Accept headers
• 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.

[elf-pavlik]

There is a related issue in Solid-OIDC solid/solid-oidc#95

My preference would be to just provide oidc vocab and revert the specific JSON-LD requirement for ClientID Documents.

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).

I don't think there was ever an intention to have two different documents. Solid-OIDC started with clients simply using WebIDs. Which later were replaced with ClientID and ClientID Document terminology.

Duplicate predicates in the interop namespace would be most likely removed. And we should pick one consistent set of predicated, be it from oidc namespace or whatever.

[justinwb]

Agree with picking one - no strong opinion on which - more important to just have one that's definitive.

[woutermont]

Agreed. The client_id and webid of an App should be the same URI, as was probably meant that way, and is semantically quite obvious. It then dereferences to a single document, which is both the WebID Profile and the Solid-OICD ClientID document. Together with aligning the vocabulary, [T]his solves a number of problems and is semantically more elegant.

EDIT: I'm not sure picking one vocabulary is a good thing here. Interop vocab should indicate data (e.g. labels) useable by Apps/Agents following that spec; Solid-OIDC vocab is meant to indicate data necessary for (Solid) OIDC flows to work. By having both live together in one document, we provide a stable foundation for Interop operations, while also allowing App developpers to switch out (or add) authentication methods.

[woutermont]

On the most urgent matter of the WebID/ClientID Document format, we have a few options:

• Have the WebID spec change it to JSON-LD by default.
• Have the Solid-OIDC spec change theirs to Turtle by default.
• Have the WebID spec mandate a Accept: text/turtle header.
• Have the Solid-OIDC spec mandate a Accept: application/ld+json header.

Personally, I don't have a strong preference. A consideration in favour of Turtle could be that it seems to be somewhat of a standard in many specs and existing applications. On the other hand, keeping JSON-LD as the default keeps up the hope of becoming compatible with OIDC (e.g. with it's Federation's Entity Statements).

[rubensworks]

Solid and in particular Solid OIDC and the WebID spec say nothing about Accept headers

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: w3c/WebID#3

[acoburn]

It is important not to conflate things.

Firstly, WebIDs can and are used to identify applications. Applications that use this mechanism will also need to be capable of managing private keys and issuing access tokens. In other words, these applications do not use the OAuth2 authorization_code flow. This is the case presently for many bots, scripts and other embedded devices that rely on flows other than authorization_code.

Second, for applications that do use the authorization_code flow, the principal agent is identified with a WebID. This is typically an individual piloting an app. That agent is also delegating access to a particular app and making use of an authorization system that is defined outside of the Solid specification, namely: OAuth2 and OpenID Connect. There is an important distinction between the agent identified with a WebID and the entity defined with a client_id. Calling both of those identifiers a WebID would create a different set of problems.

Either way, in order to work with OAuth2 and OpenID Connect, the Solid-OIDC specification uses a particular form of compact JSON-LD. This allows the Solid-OIDC specification to make use of and align with the OIDC Dynamic Registration specification. The use of a JSON flavor for serializing this document is unlikely to change. The use of JSON-LD was a compromise in order to fit both the Solid and the OpenID models, but leaving JSON altogether would break conformance with OpenID Connect: and adopting the WebID terminology for that does precisely this. There is some discussion of changing the document format of Client Identifiers to align with the draft OpenID Federation specification, but that would be JSON, not even JSON-LD and certainly not Turtle. Expecting the document format of OpenID application registrations to move away from JSON is mistaken, at least if we plan to continue to use OpenID Connect.

Because of the requirements of the WebID draft specification, it is not possible to call these Client Identifier URIs "WebIDs". And requiring these documents to be a non-JSON format conflicts with OpenID.

It is also important to note that there are many types of identifiers. WebIDs are one such type. Solid does, in fact, build significantly on WebIDs, but at no point does the Solid Protocol specification state that WebIDs are the only identifier that can be used for agents and applications. Some people in Solid are already using DIDs.

While I can appreciate that having multiple types of identifiers can introduce complexity, this is a feature not a bug of decentralized ecosystems. It is also a feature of an ecosystem that looks to the future.

[elf-pavlik]

FYI in solid/solid-oidc#95 (comment) I'm bringing up the possibility to use client_id exclusively for OIDC and following mentioned by Aaron OpenID Federation spec. While having a distinct application website for a broader solid ecosystem.

That agent is also delegating access to a particular app and making use of an authorization system that is defined outside of the Solid specification, namely: OAuth2 and OpenID Connect.

Solid Application Interoperability introduces a base of an authorization system that allows end-user to authorize applications.

There is an important distinction between the agent identified with a WebID and the entity defined with a client_id. Calling both of those identifiers a WebID would create a different set of problems.

IMO we can denote both the end-user and the application (client) with WebID or DID or something else. We should be more careful not to use the term WebID without a context of what it denotes.

---

I think we need to organize all the requirements discussed here and look for proposals that take all of them into account. The mentioned separation between client_id and application webid could be one of the directions to explore. It might be useful to have a working document where we work on this problem. Conversations can become hard to work with once they grow longer.

[tomhgmns]

There is an important distinction between the agent identified with a WebID and the entity defined with a client_id. Calling both of those identifiers a WebID would create a different set of problems.

I think I'm missing some background. It would help me if you could be a bit more precise in your statement I've quoted above so I can have an answer on the following questions:

• What is the semantic distinction between the agent identified with a WebID and the entity defined with a client_id in case this agent is an application?
• Why is this distinction important?
• Could you give a few examples of the real problems that would arise if an application's WebID and client_id would be the same? With real problems, I mean issues that are not fixable or are not about trade-offs (e.g. not supporting traditional OIDC or changing the draft WebID spec)

[tomhgmns]

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.

I agree with this point.

Be that as it may, let me rephrase my concern:
Solid and in particular Solid OIDC and the WebID spec say nothing about Accept headers even though Solid-OIDC requires the use of JSON-LD and the WebID spec implies the use of Turtle.

If both specs would allow any RDF serialisation, there wouldn't be a problem ;-)

[tomhgmns]

While I can appreciate that having multiple types of identifiers can introduce complexity, this is a feature not a bug of decentralized ecosystems. It is also a feature of an ecosystem that looks to the future.

This seems like a very strong statement without real references or examples. Could you give some examples of decentralised ecosystems in which a plethora of different identifiers have helped their growth?

Awaiting your response, I can give some counter examples of your statement:

• The email system only allows one type of identifier: an email address
• Identity systems based on blockchain only allow one type of identifier: a DID
• Linked data requires not just normal URIs, but HTTP URIs (Source)
• ...

Some people in Solid are already using DIDs.

You've provided a link to a draft document about DIDs in Solid while I actually expected a link to a list of people that already used Solid with DIDs... To the best of my knowledge, no one actually uses Solid with DIDs in a production environment, but I hope that you can give me a counter example :-)

(Also, can we please stay on topic? This discussion is about using two identifiers of the same type, i.e. HTTP URIs for a concept that is - on first sight - semantically equivalent. You are talking about using two different types of identifiers - DIDs and HTTP URIs.)

[rubensworks]

Solid and in particular Solid OIDC and the WebID spec say nothing about Accept headers even though Solid-OIDC requires the use of JSON-LD and the WebID spec implies the use of Turtle.

If both specs would allow any RDF serialisation, there wouldn't be a problem ;-)

That's a problem indeed (related to #454).

I just created #465 to tackle this specific problem.

[tomhgmns]

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:

• The Client ID document contains a reference to the WebID and
• The WebID document contains a reference to the Client ID

By doing this, we would know, for example, based on the WebID of an app, which redirect URIs are permitted.

[woutermont]

@acoburn

Thanks for the short recap for people who want to follow, but I don't see where we are conflating things.

WebIDs can and are used to identify applications. [...] [T]hese applications do not use the OAuth2 authorization_code flow.

WebIDs can indeed be used for that purpose; we do so ourselves. However, I see no reason why WebID-identified applications could not use the authorization_code flow. In fact, if applications need to have an ID dereferenceable to a profile document (e.g. like in the Interoperability draft), a WebID seems like a good fit.

There is an important distinction between the [principal] agent identified with a WebID and the entity defined with a client_id. Calling both of those identifiers a WebID would create a different set of problems.

You are right in pointing out the obvious distinction between the (social) agent using the client and the agent that is the client itself. However, I don't see why both could not be identified by (different) WebIDs. Again, the client is an agent that needs to be identified, and about which we want to declare some statements in a profile document.

[Solid-OIDC] uses a particular form of compact JSON-LD [...] [to] align with the OIDC Dynamic Registration specification [and maybe the OpenID Federation specification]. The use of a JSON flavor for serializing this document is unlikely to change. [...] [L]eaving JSON altogether would break conformance with OpenID Connect: and adopting the WebID terminology for that does precisely this. [Because of this] it is not possible to call these Client Identifier URIs "WebIDs".

I'm not sure why you are holding that against us. It is exactly this problem we want to raise once more, as you did so yourself a year ago in w3c/WebID#3 (before that issue sidetracked in a too general discussion about serialisations).

If we presume that an application needs [A] an identifier that dereferences to a profile document containing Interop data, and [B] an identifier that dereferences to a document containing OIDC data, then why on earth would we have to create two different URI's pointing towards two different resources? (And likewise with any two other ID documents.) This holds even stronger when we realise that a lot of the information in both needs to be the same. Stubbornly keeping a specification that makes it more complex for developers is a bad practice, everybody knows that.

It is also important to note that there are many types of identifiers [and] at no point does the Solid Protocol specification state that WebIDs are the only identifier that can be used for agents and applications. Some people in Solid are already using DIDs.

Definitely true, and rightly so. Now let's learn a bit about orthogonality from the DID's take on representations, and kick those default obligations out of the WebID and DID:Solid specs!

It isn't even hard; it's not like we're asking anyone to give up their preferred syntaxes. Just don't demand them on default requests:

WebID requires that servers must at least be able to provide Turtle representation of profile documents, when requested with text/turtle as the prefered format in the Accept header.

For clarity we can then possibly add:

WebID requires that servers must at least be able to provide a (i.e. any) W3C-recommended RDF-representation of profile documents, when requested without an Accept header or with an Accept header containing no acceptable formats.