Re: Relationship between WebID and DID (documents)

Good question Pierre-Antoine, let me add my personal opinion wearing no
hats but my own.

1) I think Christoph's argument, that in order for it to be linked data,
the protocol *has* to be https://, is a strong one, and providing lip
service to DID:WEB would suggest that we want to let go of that
restriction, and start allowing profile documents to live on Bitcoin Ledger
or on IPFS instead of on the WWW. If that is the case then it would make
sense to entertain this possibility not only for profile documents but also
for the rest of the data that we want to store in a user-centric way. This
then becomes almost a question for the W3C itself - do we stick to WWW or
broaden our scope to other "data storage networks" (if that's the right
word) such as single-consensus ledgers and content-addressable DHTs etc. Or
maybe the W3C is tied to WWW but Solid is not? You see how a question like
this can quickly spin out of hand if you start picking it apart. :)

2) I think the question "what is Solid" is an organisational one, that is
separate from the technical question of "what are some promising ways for
giving humans control over their data". As Melvin said, there is a
side-effect of splitting out parts of Solid into pluggable components, but
still calling the stack as a whole "Solid": if we define the solution space
too broadly then there is a risk of unresolvable discussions. If we say the
profile document technology is out of scope for Solid then we have to
really mean it. We would have to be willing to say Solid is just a small
part in a larger puzzle, and for instance leave open the question whether
Solid will even work in standard web browsers. Like many projects, I think
most of us are motivated to build a stack that works well end-to-end for
some real use cases, and building just a smaller pluggable part without
getting a say in how that part will benefit the end users is less exciting.

3) I think the point Pierre-Antoine mentioned about public (max-sharing)
profile documents vs private (min-sharing) unlinkable identities is a
second fundamental difference between the thinking behind WebID vs the
thinking behind DID:WEB. Technically they may amount to the same, but
thinking back 10 years ago, the discussions we had about Federated Social
Web, with Diaspora, StatusNet, and FOAF+SSL at the time, the big problem we
were solving was to build "something like Facebook" in a federated way. And
Facebook was very much about max-sharing, it was what allowed its success,
both in terms of voyeurism and gossip as the ultimate driver of engagement
in terms of data mining opportunities. Whatever you did on Facebook
(events, discussions, likes, ...) had an avatar next to it, and a link to a
public profile from which more information about that person's recent
activities was discoverable. I think that was a big part of why public
profile documents got such a big role to play in the design of Solid.

Tying 2) and 3) together, we have to ask ourselves if we still strongly
believe in public profile documents as drivers of the web of "Social Linked
Data", or if our thinking about max-sharing vs min-sharing has changed in
the past 10 years, and if it has changed, then we need to ask whether we
want to adjust the foundations of the Solid project to shift away from
max-sharing public profile documents or not. If we stick to the concept of
public profile documents then we definitely have a good reason to say Solid
builds on WebID and this is fundamentally different from DID:WEB. And even
if we move away from max-sharing then I think Christoph's argument from 1)
is still a good reason to want our identity system to stick to the Linked
Data principles, the design of the WWW, and the protocols that current
browsers support.


Cheers,
Michiel


On Wed, 29 Nov 2023 at 21:44, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> st 29. 11. 2023 v 17:15 odesílatel Pierre-Antoine Champin <
> pierre-antoine@w3.org> napsal:
>
>> 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 :
>>
>> * 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.
>>
>> * 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. A 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)
>>
>> * 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.
>>
>
> Other way round.  The scope of solid is too broad.  DID spec is a
> controversial spec with multiple, formal objections from major W3C players,
> against it.  Inclusion of DID in the charter will almost certainly lead to
> legitimate formal objections down the line, which is an unnecessary risk.
> WebID is a perfectly good standards compliant identity system, and it's
> going to be more than enough work to standardize that, in this WG.
>
>
>>
>> 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]
>> https://github.com/solid/solid-wg-charter/issues/39#issuecomment-1829420164
>> [2] https://github.com/solid/solid-wg-charter/issues/39
>> [3] https://www.w3.org/2005/Incubator/webid/spec/identity/
>> [4] https://www.w3.org/TR/did-core/
>> [5] https://w3c.github.io/vc-controller-document/
>> [6] https://w3c-ccg.github.io/did-method-web/
>> [7] https://solid.github.io/did-method-solid/
>>
>