Re: Relationship between WebID and DID (documents)

Dear Pierre-Antoine, dear all,

I am not part of the WebID CG or DID CG, so please do correct me if you 
are and know better than me.

Nonetheless, I would like to offer some arguments and opinions (based on 
my work with both WebIDs and DIDs over the recent years):

The DID spec is a W3C Recommendation that defines among other things:
- a URI scheme (for DIDs)
- a data model of a DID document
- the abstract operations of a DID method to interact with a DID document

It does explicitly not specify a protocol using which one may obtain the 
DID document for a DID.
These protocols are defined by the specific DID methods which are not 
part of the W3C Recommendation.
As of writing this, there are currently 183 known DID methods [1], and 
did:web is one of them.
There does not exist a DID method specification that has the status of a 
W3C Recommendation (see also the formal objections to the proposed 
Recommendation [2]).
Using DIDs also means to not follow the Linked Data principles [3].

The WebID spec is a W3C Editor's Draft that defines among other things:
- to use HTTP URIs (for WebIDs)
- a non-normative data model of a WebID profile document

By specifying WebIDs as HTTP URIs, the spec provides a specific URI 
scheme and protocol (and by the choice made the corresponding HTTP 
methods) using existing Web standards.
This is the usual practice for identifying any thing when following the 
Linked Data principles.

These arguments in mind, on your thoughts, pa:

 > * some people might argue that WebID is trying to solve a problem for 
which we already have a W3C standard (namely, DID); they might be 
encouraged in this thoughts by the similarity between both abstracts, 
and by the fact that WebID largely predates DIDs (and could be seen as 
an early attempt, now superceded). If we disagree, we need to clarify 
why WebID are still needed.

In my mind, the WebID spec is not comparable to the DID spec alone, but 
only to the combination of the DID spec plus the specification of a DID 
method. Otherwise, the protocol specification is missing.
Therefore, I am quite hesitant to call the discussion WebIDs versus DIDs 
because there is a fundamental part missing.

 > * one possible argument to continue using WebID instead of DIDs is 
that WebIDs are more straightforward, being HTTPS URIs, while DIDs 
introduce a level of indirection via DID methods.  counter argument 
would be: "use the did:web method [6], you will combine the convenience 
of HTTP with the extensibility of DIDs". (I know that a did:solid method 
[7] was also considered, but I don't know how it differs from did:web)

WebIDs vs did:web would a more adequate discussion in my opinion.
Assume the community decides to go with did:web:
Would then bringing did:web to W3C Rec also be a deliverable of the WG?

One may argue for a discussion of WebIDs versus {DIDs + methods x,y and 
z}, i.e., more DID methods.
Then, there should be a discussion on every single method that Solid 
should/would support:
If one would like to simply allow DIDs of any method to be used, then 
SOLID-OIDC becomes DID-OIDC which would be fun but not specific to Solid 
At this point I would question why DID-OIDC would be a deliverable of 
the Solid WG.

In the same vein, I would like to voice my personal opinion on what the 
WG should aim for:
I believe that the Solid protocol should be a well-defined standard 
without any loose ends.
Especially for identification, authentication and authorization, we 
should aim to create a finished standard without relying on some draft 
of a specification somewhere else on the Web where the WG does not have 
any influence.
Otherwise, we risk the security of the Solid protocol and, with that, 
any chance of adoption.



On 29/11/2023 17:14, Pierre-Antoine Champin wrote:
> Dear all,
> this has been on my mind for a while, but what triggered this email is 
> Jacopo's recent ping [1] to the Solid Community.
> Disclaimer: I have not been following closely the activity of the 
> WebID CG, so apologies if I am rehashing a discussion that already 
> happened, or inappropriately throwing a cat amongst the pigeons.
> Solid is highly relying on WebID, to the point that it was consider, 
> in the first charter proposal, to adopt WebID as a deliverable of the 
> future Solid WG [2]. But in the spirit of improving our charter 
> proposal, and to respond to the TAG's (and others') concerns, we need 
> to show that we are not stuck on a specific solution, and taking into 
> account what exists elsewhere, in particular in other W3C WGs.
> Reading the abstract of the WebID spec [3]:
> > A global distributed Social Web requires that each person be able to 
> control their identity, that this identity be linkable across sites - 
> placing each person in a Web of relationships - and that it be 
> possible to authenticate globally with such identities.
> While the abstract of the DID recommendation [4] states:
> > Decentralized identifiers (DIDs) are a new type of identifier that 
> enables verifiable, decentralized digital identity. A DID refers to 
> any subject (e.g., a person, organization, thing, data model, abstract 
> entity, etc.) (...) the design enables the controller of a DID to 
> prove control over it without requiring permission from any other 
> party. (...)
> Furthermore, WebID and DIDs have in common that both can be 
> dereferenced to a document describing the entity they identify, and 
> that this document is Linked Data -- although for DIDs, it is bound to 
> be (a very constrained form of) JSON-LD. Note also that the Verifiable 
> Credentials WG is working on the notion of Controller Document [5] -- 
> in my understanding, this is a generalization of DID documents, 
> focused on the needs of VCs, and /not/ necessarily retrieved from a DID.
> So, here are a few thoughts :
> [2 commented above]
> * regardless of the outcome of the previous points (keep using HTTPS 
> WebIds vs migrate to did:web DIDs), the similarity between WebID 
> documents and DID/Controller documents should be acknowledged. Note 
> that the differences should also be emphasized: WebID documents are 
> usually expected to contain identifying information about the subject 
> (name, contain details...), while the general advice for DID document 
> is to contain minimal information (if any) beyond the criptographic 
> material required to prove control over the DID. I do not consider 
> these difference to be ingerent incompatibilities, I believe they stem 
> from focusing on different use-cases. DIDs are focusing on scenarios 
> where privacy / pseudonymity is important, so a user is expected to 
> have several DID, and want them to be unlinkable. WebIDs are focusing, 
> on the other hand, on reusing a single identity across several 
> services (linkability being a feature, not a bug). But both solutions 
> could be used in both categories of use-cases.
> To conclude: my goal here is not to dismiss anyone's work, but to try 
> and clarify our position w.r.t. other (published or in-progress) W3C 
> standards. This will be useful for chargering the Solid WG, but this 
> is a good thing to do in general, IMO.
>     best
> [1] 
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]

Received on Wednesday, 29 November 2023 19:21:09 UTC