Useful features from did:webs -- signed files in the DID path and "whois"

[swcurran]

After a discussion last week between the did:webs working group at ToIP and the did:webplus team, I shared a note about some of the important features of did:webs for consideration in did:webplus.

For the most part, the goals of the two web-based DID methods are the same:

• An evolution of did:web that adds verifiability
• A chained, verifiable history of the DID and the DIDDocs published by the controller
• Support for the pre-rotation of DIDs to enable recovery if needed.

The two methods vary in how that is done. did:webs uses a KERI "audit log file" that allows a resolver to process the events to verify that they are all valid, and that they produce the same DIDDoc as is published with the audit log. As the controller evolves the DID, they publish new versions of the current DIDDoc and the audit log. did:webplus publishes and retains all DIDDocs, versions them, and cryptographically links the files.

The additional features of did:webs that I think are valuable in any web-based DID method, including did:webplus, are signed files and the "whois" folder. From the full did:webs spec, the source description of these features can be found here for signed files and here for the whois folder. I recommend that you consider adding them to did:webplus.

In did:webs, the following additional goals are defined:

• self-certifying identifiers
• support for multi-sig DIDs
• audit log transactions for some uses of the DID (e.g. when signing files published in the DID path)
• the formalization of how a DID controller can notify others about the redirection of the DID from one HTTPS URL to another through the use of the "id" and "alsoKnownAs" DIDDoc entries. Used, for example, in the case where two companies merge, but they want the "old" DID identifiers used in verifiable credentials or published elsewhere to still be verifiable.

[vdods]

Thank you for the detailed comments, Stephen.

Signed files and the whois folder indeed seem like good features. Is there any requirement of (or desire for) an immutable and/or non-repudiable history for signed files? I'm working on related concepts at the moment, and wonder if there might be something generalizable here.

In particular, there's a requirement (e.g. in https://github.com/LedgerDomain/did-webplus/issues/8) to maintain an external copy of DID microledgers for purposes of long-term non-repudiability, service availability, and detection of deletion or attempts to alter a DID's history. Should signed files be part of this? It seems that if signed files, and in particular a "whois" folder is meant to be a formal part of a DID method, then they must be included. What do you think?

[bumblefudge]

did:webplus publishes and retains all DIDDocs, versions them, and cryptographically links the files.

versioning them, linking them, signing them is all done in a way that witnesses can cache/replicate them using straightorward web technologies rather than a trusted client-- this is a crucial feature! I think the flexibility of the witnessing is a strength of this approach, its lightweight microledgers can be witnessed and tracked in multiple ways (git, ipfs, waybackmachine, etc etc) rather than hardcoding one and making it mandatory in the spec, the spec remains a thin layer composable with many other mechanisms.

The additional features of did:webs that I think are valuable in any web-based DID method, including did:webplus, are signed files and the "whois" folder. From the full did:webs spec, the source description of these features can be found here for signed files and here for the whois folder. I recommend that you consider adding them to did:webplus.

Why is this part of the did:webs spec, tho, and not a separate spec? Feels orthogonal and not all webplus/webs users would want to embrace that trust model or discovery mechanism.

Imagine a system that is using did:webplus and the indic.io/TBD trust-establishment/credential manifest mechanism for discovery of those ecosystem credentials. for a specific use-case or customer, they want to bolt on did:webs support to their did:webplus server-- if they don't also need the whois stuff, why should they have to also reimplement/parallelize that second set of discovery mechanisms and features?

In did:webs, the following additional goals are defined:

• self-certifying identifiers

I'm a fan in general but I'm not sure they're needed for the use-cases webplus targets?

• support for multi-sig DIDs

I'm a fan in general but I'm not sure they're needed for the use-cases webplus targets? Even if they were, traditional single-key/single-controller DIDs can multisign multiple other ways (linked data VCs can just have multiple proofs objects, JWS signatures can wrap one another, Chris Allen is working on Schnorr signatures...). I don't think we need to break the assumptions of the W3C DID spec to have multiple signatures.

• audit log transactions for some uses of the DID (e.g. when signing files published in the DID path)

This feels like a layer violation-- better handled by the witnessing/auditing layer, which doesn't need to make the DID layer itself more complicated.

• the formalization of how a DID controller can notify others about the redirection of the DID from one HTTPS URL to another through the use of the "id" and "alsoKnownAs" DIDDoc entries. Used, for example, in the case where two companies merge, but they want the "old" DID identifiers used in verifiable credentials or published elsewhere to still be verifiable.

I hadn't thought about this one at all! What about

{
  'id': "did:web:example1.com:{hash of did current did doc}",
  'nextKey':{pkh2},
  'assertionMethod':{pkh1} 
  ...
}

{
  'id': "did:web:example2.com:{hash of did current did doc}"
  'alsoKnownAs':["did:web:example1.com"]
  'prev':"did:web:example1.com:{hash of did current did doc}"
  'assertionMethod':{pkh2}
}

[swcurran]

Thank you for the detailed comments, Stephen.

Signed files and the whois folder indeed seem like good features. Is there any requirement of (or desire for) an immutable and/or non-repudiable history for signed files? I'm working on related concepts at the moment, and wonder if there might be something generalizable here.

In particular, there's a requirement (e.g. in #8) to maintain an external copy of DID microledgers for purposes of long-term non-repudiability, service availability, and detection of deletion or attempts to alter a DID's history. Should signed files be part of this? It seems that if signed files, and in particular a "whois" folder is meant to be a formal part of a DID method, then they must be included. What do you think?

AFAIK — the plan is that the KERI log/event stream will include the signing events for the files, so for long term-non-repudiability, it is available. I think it is a good idea. Even though the signing events don’t impact the DIDDoc, I think they should be part of the audit trail.

For did:webs the KERI event stream file beside the DIDDoc is the “DID micro ledger”. Our assumption is that any changes to the DIDDoc and. the microledger are always published together and available to resolvers via HTTPS GETs.

[swcurran]

From @bumblefudge:

Why is this part of the did:webs spec, tho, and not a separate spec? Feels orthogonal and not all webplus/webs users would want to embrace that trust model or discovery mechanism.

Imagine a system that is using did:webplus and the indic.io/TBD trust-establishment/credential manifest mechanism for discovery of those ecosystem credentials. for a specific use-case or customer, they want to bolt on did:webs support to their did:webplus server-- if they don't also need the whois stuff, why should they have to also reimplement/parallelize that second set of discovery mechanisms and features?

Why have this? Because an issuer providing more data than “fits” in a DIDDoc is a useful feature in many scenarios, and because it is so dead simple to do in web-based DID. It completely fits with the DID Spec (DID URL paths), so any DID Method can do it, but is particularly simple for web-based DIDs — controllers and resolvers.

Combining signed files and whois as part of this spec should be done (I think) because they enable incredibly useful features using a dead-simple implementations. Given the power and simplicity, I think it gives a major reason for adoption — that works nicely with did:web, if you trust the controller.

I think a secure web-based DID method can eliminate the use of most other DID methods — except did:peer and did:key.

[bumblefudge]

Why have this? Because an issuer providing more data than “fits” in a DIDDoc is a useful feature in many scenarios, and because it is so dead simple to do in web-based DID. It completely fits with the DID Spec (DID URL paths), so any DID Method can do it, but is particularly simple for web-based DIDs — controllers and resolvers.

Sorry, I think you're answering a different question. Why do they have to be ONE SPEC and both mandatory/coupled, is my question. Someone who wants did:webplus without the "whois" functionality is forced to do both if they're one spec. Someone who wants to do both loses nothing by implementing two separate specs.

[bumblefudge]

I think a secure web-based DID method can eliminate the use of most other DID methods — except did:peer and did:key.

Here I disagree, because I think that web3 and web5 (insofar as either of those are a thing that exists and will continue to develop) are increasingly defined by wallets being the primary user agents (not the browser) and offline or onchain "backends"; in many web3 use-cases, wallets and nodes interact directly, without any web servers or HTTPS or DNS-based trust! When I was working with KYC for Web3 use-cases, many DeFi developers would say to me, "no, I'm not setting up a web backend just for your app; we use a PWA with no backend beyond the blockchain node". It's a wild new world out there, with totally different trust models!

But yeah, in use-cases where people aren't already clustered around a blockchain and have more DNS-based trust than DPKI-based trust, i.e. most other use-cases, did:webplus and/or did:webs would be incredibly useful!

[swcurran]

But yeah, in use-cases where people aren't already clustered around a blockchain and have more DNS-based trust than DPKI-based trust, i.e. most other use-cases, did:webplus and/or did:webs would be incredibly useful!

To be clear — the trust is NOT DNS-based or PKI based, but the event stream that created the identifier and evolved it and secured it. The web is used as the discovery mechanism for the DID information about the identifier — not the basis of trust. I can put a did:webs on GitHub and it will work just fine, with no trust needed in GitHub other than it will serve files.

Agree that others will still want to use ledger-based DIDs and that’s fine.

[swcurran]

Sorry, I think you're answering a different question. Why do they have to be ONE SPEC and both mandatory/coupled, is my question. Someone who wants did:webplus without the "whois" functionality is forced to do both if they're one spec. Someone who wants to do both loses nothing by implementing two separate specs.

No one is forced to have a whois, or to have anything in it. It just means that if they do, there is a definition of what is needed for the content. This could move to the DID Core spec. as appropriate, but a super useful feature that is simple to implement in the web-based DID method spec, it makes it attractive to use.

[bumblefudge]

No one is forced to have a whois, or to have anything in it. It just means that if they do, there is a definition of what is needed for the content.

Interesting. Does it obligate the resolver in any way? Are there whois contents/properties that change the mechanics of the did resolution in any way? If it changes nothing about DID controller behavior or DID resolver behavior, then why should it be in a DID method spec and not its own spec?

I'm not sure it would work moved into DID core, because I can't see it working equivalently and interoperably for many of the architectures targeted by the DID WG use-cases doc... but I'd have to think about it. I've got no problem with it, to be clear, I just like smaller specs and see no strong benefit to coupling them.

[bumblefudge]

the trust is NOT DNS-based

I would argue that a domain name means nothing to DID resolvers unless there is reputational/social/business trust being anchored to control of a domain. So in the technical sense of the word trust, sure, the trust is key-based. But the discovery mechanism inherits social/real-world trust from our societal and economic trust in the DNS/ICANN system! Sorry I wasted time speaking imprecisely.

[swcurran]

I guess it would be in the DID Resolver spec vs. core, but it would think it would certainly be implementable in any DID Method. It defines what MUST happen when resolving the “/whois” path on a DID. But for now, we are just saying “This is what MUST happen when you resolve the “/whois” path of a did:webs DID."

[bumblefudge]

It defines what MUST happen when resolving the “/whois” path on a DID.

Oh, that makes a lot more sense! I was assuming it was a /whois path off example.com, not the did:webX:example.com:whois path. Carry on! The DID Resolution spec might actually get some love if the DID WG spins up again, it would be cool to see DID Paths specified this way. I suppose there would need to be some kind of default 404-equivalent for when a method doesn't support that path (or any paths)? Looking forward to that discussion, on issues of another repo! Tag me in it when you see it forming 😄

[swcurran]

To be clear — did:webX:example.com/whois (not :whois)

Note that with “did:webs”, there is always an AID as the last “:” component of the did, so for did:webs if is did:webX:example.com/123456/whois. That eliminates the sticky .well-known issue with did:web. But you get the idea...