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

[dmitrizagidulin]

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

[justinwb]

Fully support incorporating DID into the Solid ecosystem!

[creatinglake]

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

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

[csarven]

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

[csarven]

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?

[dmitrizagidulin]

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

[dmitrizagidulin]

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

[RubenVerborgh]

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.

[dmitrizagidulin]

(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

[csarven]

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.

[RubenVerborgh]

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.

[mwherman2000]

(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

Unfortunately, despite the title, this presentation only mentions "Self-Sovereign Identity" as a keyword in its word map with no further mention.

Issue

Perhaps this should be opened a separate issue: what is in the Solid architecture (or in the architecture roadmap) in terms of supporting the Self-Sovereign Identity model? ...the current design of the content access controls based ACL system isn't sufficient.

Context

For example, to fully realize the SSI model in Solid, I not only want to specify access controls but also usage controls (in terms of usage license controls) whereby the consuming app needs to agree to example terms like:

• App X can refer to but can not read and persist my content to any external storage system (beyond where the original content currently resides) without my expressed permission.
• App X cannot attach it's own ancillary information to my Identity (e.g. WebId) without my expressed permission.
• App X can read my content but cannot aggregate it (anonymously or not) to create its own new content without my permission.
• etc.

Questions

1. Is it envisioned that Solid will support these sorts of usage license terms ...as part of an end-to-end lifecycle? Is this type of support weeks, months, or years away? Is it on the roadmap?

2. Is there anything that needs to be changed in the current Solid architecture to support usage license terms? ...or has Solid been architected to make usage license terms a relatively straight forward design/implementation detail?

Best regards, Michael Herman Self-Sovereign Blockchain Architect Trusted Digital Web Project Hyperonomy Digital Identity Lab Parallelspace Corporation

[bblfish]

Btw, I think there is a half way point from WebID to DID which goes via https based KeyIDs.
See the HttpSignature proposal (updated 11-Feb-2021) for an example. This is very easy to implement and resolves the problems mentioned above, as the key can be published anywhere without needing to link to a WebID.

[elf-pavlik]

For example, to fully realize the SSI model in Solid, I not only want to specify access controls but also usage controls (in terms of usage license controls) whereby the consuming app needs to agree to example terms like

Could you please clarify how app needs to agree to supposed to work? In still open PR to Application Interoperability Specification you can find some example consent screens. Would you see such application terms of service appropriate to present there to the user so that they can decide if they will authorize that application to access data on their behalf or not? I think it might be helpful if user's authorization agent also included ranking and ToS breakdown from https://tosdr.org/en/frontpage or other similar effort.

I think in practice, app would have some terms of service and user would accept them and use the app or not and don't give it any authorization. I can't clearly see app agreeing to since piece of software doesn't seem fit to make choices like that or have any liability based on those choices. Service agreement seems to me something that would be made between application user and application provider, unless user uses self hosted application which I would encourage in solid and work on ecosystem making it as easy as possible.

BTW I think we might be drifting away from original topic of this issue. If you see it relevant for mentioned Application Interoperability Specification we could create tracking issue for it in https://github.com/solid/data-interoperability-panel

[mwherman2000]

BTW I think we might be drifting away from original topic of this issue. If you see it relevant for mentioned Application Interoperability Specification we could create tracking issue for it in https://github.com/solid/data-interoperability-panel

I believe this is an architecture principles and architecture requirements issue (vs. data interoperability issue) (if accepted). It may progress to becoming a rights management issue but I think it is much larger than that.

I'll open a new issue under Specification and post my reply there: https://github.com/solid/specification/issues/222

[bblfish]

I was really intrigued that the picture @dmitrizagidulin uses to show the relation between WebIDs and DID uses a hash url for the DID. I checked and indeed the RFC 8141: Uniform Resource Names (URNs) does allow it. I did not know that!

I think with this one could much improve the whole explanation in the DID chapter by @peacekeeper and @talltree in the very helpful book Self Sovereign Identity soon to be published by Manning. They illustrate how DIDs function with this very nice diagram:

which is clearly very similar to the WebID spec diagram from 2014 which I add below for comparison. There URL without the hash refers to the document and the URL with the hash refers to the person.

Notice though that the difference is that in WebID we only need 1 type of semantic relation from a URI: the reference relation. The "sense" relation underlies the reference relation by pointing into the graph, as explained by the fragment section of the URI specs. That is known as a pointed graph by mathematicians.

That fits the RDF semantics spec: which assigns a reference to each URI. The "describes" relation is one from the pointed graph to the object in the world.

With DID URNs with fragment identifiers you can simplify the picture in just the same way, in fact they could then be shown to be equivalent. That may make reasoning much simpler in many other ways. Note that verifiable Credentials are actually 3-4 regular hypergraphs, so a hash DIDs is what mathematicians would call a pointed 3-4 regular pointed hypergraph. (see my slides from the 2010 SemWeb Pro Applied Category Theory Workshop).

With this one could have a nice and unified account of DIDs function and WebIDs function.

[bblfish]

So having thought about I am +1 on @rhiaro and @dmitrizagidulin did:web. We can try this as an experiment at least to start off with. Indeed Solid can help fill the DID method operations part of that spec. These need to be automatiseable if browsers are going to implement them. Again quoting from the book Self Sovereign Identity, which I highly recommend, page 179

The four basic operations that can be executed on a DID:

• Create: How can a DID and its associated DID document be created?
• Read: How can the associated DID document be retrieved?
• Update: How can the contents of the DID document be changed?
• Deactivate: How can a DID be deactivated so it can no longer be used?

This maps nicely to Solid. We can do it as follows. Let us name the function u2d: URL → DIDWeb, somewhat along the lines defined in the DID:web spec, and the inverse function d2u: DIDWeb → URL that goes in the inverse direction. Here DIDWeb is the type of all did:web:... urls.

• Create: POST to an ldp:Container which returns an https URL for the content u, which can then be transformed to a did:web:... url as followsdw: DIDWeb = u2d(u)
• Read: HTTP GET on the above returned did:web:... DW transformed to an https URL. ie GET d2u(dw)
• Update: use HTTP PUT or PATCH on the did:web:... url i.e.PATCH d2u(dw)
• Deactivate: use HTTP DELETE on d2u(dw) i.e. DELETE d2u(dw)

It would need some careful review of the did:web:... spec still, for example to check that the mapping to WebIDs which I pointed to in my previous comment works right. Given that LDP is a w3c standard we don't I think need to make another did:solid or did:ldp spec.

The Self Sovereign Identity book adds that one should add Security and Privacy considerations, and here we can use Solid Web Access Control to limit access to such a did:web document in a very fine grained manner.

[bblfish]

Looking at @rhiaro and @dmitrizagidulin's did web spec I think it is a bit limited as it seems to only allow DID's to be placed in particular locations on the web server's file system. We can easily make this a lot more flexible by using the name-space part of a URN. This would allow for DIDs like this did:web:alice.pod/keys/k1. The mapping from did:web to https urls would then be very simple: replace did:web with https://. Then we can place the DID documents anywhere on the file system of a Solid server, and even allow multiple keys to be placed there.

[rhiaro]

I haven't read this whole thread, but just dropping in as @bblfish tagged me. AFAIK the did:web spec is still a work in progress. Please do open issues with parts that don't gel well with solid and we can look at aligning. I personally haven't actually done a lot/any of the work on the did:web spec to date, so opening issues there would also alert the other editors about potential problems. (and my personal opinion is also that the .well-known discovery stuff is.. not my favourite. Can't speak for the other editors or any other implementors, but I would be interested in concrete use cases that might allow us to move away from that at some point.)

[bblfish]

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.

[bblfish]

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.

[bblfish]

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.

[dmitrizagidulin]

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

[bblfish]

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.

[bblfish]

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

[abhishekmaha-tno]

Have there been any updates on this issue?

[csarven]

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.

[dmitrizagidulin]

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

[abhishekmaha-tno]

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

[mave99a]

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.

[dmitrizagidulin]

Thanks @mave99a!

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