Proposal: Support Decentralized Identifiers (DIDs) in addition to Web IDs

This is a placeholder proposal for the Solid project to support Decentralized Identifiers (DIDs), in addition to Web IDs.

Similarities:

Both DIDs and Web IDs are URIs (follow the URI RFC), both resolve to a Linked Data document
Both are used as identifiers for individual people, organizations, services, and other entities
Both are intended to store Public Key material, for uses such as authentication
Both store links to documents or API endpoints (such as preferences, OIDC Issuers, etc)
Essentially interoperable

Differences:

PII: In addition to key material and links, Web ID Profiles also contain Personally Identifiable Information (PII) such as User Profile Info (name, email, user picture), or the user's Social Graph (using things like foaf:knows). DID Documents, on the other hand, are required (due to GDPR pressures and similar) to not store any sort of PII, as much as is possible.
Vocab: Web ID Profiles use a combination of foaf, solid and cert vocabularies. DID Documents use the did vocab.
Key Type Support: DIDs use the Linked Data Proof and Linked Data Signatures specs, and support a wider array of key types (RSA, Ed25519, Curve25519, Secp256k1, etc) and purposes (authentication, digital signatures, encryption, delegation, capability invocation)
Storage and Resolution mechanisms: There are many different DID methods; some of them store their DID Documents on distributed ledgers, some of them on the Web (see the did:web method), some on IPFS, some on IoT devices, etc.
W3C Level of Standardization: The DID spec has been incubated for 3 years in the Credentials Community Group, and is now an official W3C DID Working Group.

(Inrupt, as well as the Solid community, should join the DID WG!)

Fully support incorporating DID into the Solid ecosystem!

I fully support this effort as well! Solid and DIDs are synergistic.

Yes, but which resolvers, and how will this work in the browser?

I’m all for DID, but what is the subset implementers MUST support? That is the issue.

What's the essential difference between did:web: and http: ? What's possible with did:web: that's not possible with http:?

did:web: isn't yet a registered method but I'm sure that can change easily.

A DID document is represented in JSON-LD and its context uses an HTTP URI ( eg https://w3id.org/did/v1 ) ... So, HTTP all the way down?

@RubenVerborgh

@RubenVerborgh

Yes, but which resolvers, and how will this work in the browser?
I’m all for DID, but what is the subset implementers MUST support? That is the issue.

Excellent questions. So, the specs do not, at the moment, specify any required subset.
You're right, that'll be one of our main decisions - which DID methods to support?

I'd advocate for starting with the did:web method (since it aligns the closest to the Solid ecosystem), and then add support for others as time/resources/usecase permits. (And, all the required libraries do work in the browser.)

@csarven

@csarven

What's possible with did:web: that's not possible with http:?

The way I figure it, the important part is the data model / shape of the DID Document. It could either be linked to via an https or a did:web link.

then add support for others as time/resources/usecase permits

But it’s not about our resources though. It’s about what we put as a MUST in the spec.

Only those DID resolvers with a MUST can ever be chosen safely for a WebID. All the others risk being unsupported by any given app.

(Reference / further info) There was an excellent introductory presentation on DIDs on this week's Credentials Community Group call that might also be useful to this community:

Decentralized Identifiers (DIDs) & Self-Sovereign Identity (SSI): A Non Technical Discussion

did:web may be in conflict with the following criteria from the DID spec ( https://www.w3.org/TR/2019/WD-did-core-20191209/#did-method-schemes ):

The method-specific-id value MUST be able to be generated without the use of a centralized registry service.

in that domain names and IP address assignments are handled by ICANN and IANA. Putting the challenge around resolving aside, DID's notion of "centralized" and the requirements thereof is particularly important if http-based WebIDs are intended to (or can ever) work under did:web.

The method-specific-id value MUST be able to be generated without the use of a centralized registry service.

I don't see an objection in the way that it is currently phrased, in the sense that DNS is able to be realized in a non-centralized way. It just so happens that most implementations today are rather centralized.

Actually for the HTTP-Signature Protocol for Solid I can see the use for a public key DID, ie. a URN that contains the public key directly in the URN, a bit like one can have data urls. This would allow one to send an HTTP request using the HTTP Signatures spec developed at HTTP-bis WG like this:

GET /protected/resource
Credential: >/creds/age<
Signature-Input: sig1=(); keyId="<did:key:rsa:dsf234....>"; created=1402170695
Signature: sig1=:cxieW5ZK...

And the server would then using P2P extension for HTTP/2 be able to take on the role of a client and on the same connection ask for the relative URL

GET /creds/age

The server could on receipt of this credential (or proof) be able to save it in its cache under <did:key:rsa:dsf234..../creds/age> so that when the client the next time comes with that keyId the server could immediately fetch the credential in its store without needing to make a request to the server. After all the server knows nothing about the client other than it's public key and so it may as well name it as that.

Ah, so there is a did:key method, which one could get inspiration from. Perhaps we can build on their work? I.e. for the use case I described above, what would be needed is to add paths to a did:key:dsf234..., which could be used by a server to then do GET, PUT, POST, DELETE on content on the client using the same connection. So even though the did:key: cannot be edited, <did:key:rsa:dsf234..../creds/age> could be using Solid and the P2P extension to HTTP/2 or something similar.

I have added an example using did:key and links to the Universal Wallet and Verifiable Credentials specs in the new HTTP Sig protocol for Solid Authentication page.

@bblfish

@bblfish - I know you are a big fan of HttpSignatures. So am I. Huge fan; I help with the spec, and I contribute to the development of http sig libraries in js.

You're mixing a bunch of things into the same pot. HttpSignatures are not an authentication mechanism.
They are a proof of key possession mechanism. It's used by some authentication and authorization protocols (like GNAP), along with DPoP and MTLS.
Yes, you can hand-roll your own authentication protocol on top of HttpSignatures. But why? What use case does it serve? Why not use one of the existing ones?

For example, if you want a DID-compatible authentication, there are other protocols for that out there (like DID-SIOP). And our current Solid-OIDC spec is entirely DID-compatible.

Similarly, Verifiable Credentials are not for authentication either. Specifically and explicitly. They definitely have a place in the Solid ecosystem, but not in the way you're using them...

Since Nov 2014 the Http Signatures spec has integrated WWW-Authenticate: Signature realm="Example" header returned with a 401. I am aware that each community has different definitions of what counts as authentication, but that is enough for our use case. I implemented it on the client and on the server around 2015 and integrated it with WebID, started writing a library for it and sent in PRs for the draft-cavage spec.
The other protocols are useful, but this is the most efficient one and has the longest track record. It is also the most minimal. Actually it can be explained in a page. The HttpSig document I wrote is mostly use case explanation. (I should split it into two documents: one for the protocol extension to "Signing HTTP Messages" IETF work and move the use cases into a separate document to make that clear.)

I need to implement it again next week, so that will allow me to send feedback to the IETF HTTP-Bis mailing list to test out the slightly changed signature mechanism. If "Signing HTTP Messages" is also used by OIDC then all the better: the code will be useable by them too.

Should we support did-jwt? I opened an issue on the authentication panel issue 157.

Have there been any updates on this issue?

One update is that there is an early draft for the did:solid method: https://solid.github.io/did-method-solid/ (Repo: https://github.com/solid/did-method-solid ). That was published before did:web had some (significant?) revisions, so we need to review.

@abhishekmaha-tno

@abhishekmaha-tno - I'm not sure, regarding updates (in terms of, it's not clear that Solid leadership is a fan of this proposal). I do have an implementation of this in my solid implementation, but that's not really helpful to CSS users.

@csarven

@csarven - Thank you for the update! I see that the efforts are still in a preliminary stage.
@dmitrizagidulin - I'm quite interested to see this, could you please link to the repository/code? (Also curious why Solid leadership may not like the SSI concept - the pragmatic approach appears to me to adopt standards with greater public adoption/interest, or at least to support both)

Thanks for Sir Tim Berners-Lee’s support now DID is officially a W3C recommendation, DID and Solid could be great companions, each of them solve a different problem and could enhance each other. I don’t see a reason why this can’t become a reality.

There was an unofficial fork of Solid for DID support:
https://github.com/interop-alliance/life-server

But it would be great if the support is official.

@mave99a

Thanks @mave99a!

@abhishekmaha-tno - yeah, life-server is the fork I was referring to.

Navigation Menu

Repository navigation

Proposal: Support Decentralized Identifiers (DIDs) in addition to Web IDs #217

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Proposal: Support Decentralized Identifiers (DIDs) in addition to Web IDs #217

Description

Activity

justinwb commented on Sep 18, 2019

creatinglake commented on Sep 18, 2019

RubenVerborgh commented on Sep 18, 2019

csarven commented on Sep 18, 2019

csarven commented on Sep 18, 2019

dmitrizagidulin commented on Sep 18, 2019

dmitrizagidulin commented on Sep 18, 2019

RubenVerborgh commented on Sep 18, 2019

dmitrizagidulin commented on Oct 8, 2019

csarven commented on Dec 30, 2019

RubenVerborgh commented on Dec 30, 2019

mwherman2000 commented on Jan 17, 2021

7 remaining items

bblfish commented on Feb 11, 2021

bblfish commented on Feb 11, 2021

bblfish commented on Feb 13, 2021

dmitrizagidulin commented on Mar 12, 2021

bblfish commented on Mar 12, 2021

bblfish commented on Mar 28, 2021

abhishekmaha-tno commented on Sep 5, 2022

csarven commented on Sep 6, 2022

dmitrizagidulin commented on Sep 8, 2022

abhishekmaha-tno commented on Sep 8, 2022

mave99a commented on Sep 14, 2022

dmitrizagidulin commented on Sep 14, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions