Spoofing did:webs didDocs about tswg-did-method-webs-specification

[SmithSamuelM]

@swcurran

My understanding was that there is (is going to be?) a “KERI-way” event to indicate that DID associated to the did:webs location. My understanding was also that there would be a further way a way to say “Here is the new did:webs DID for this AID” that could be used to add an “AlsoKnownAs” entry into the DID for an old web location to be used in case of redirections, the merges of organizations, etc. — any situation where the controller wants to indicate the have deliberately moved the document.

Yes you are correct, the method that @pfeairheller proposed and that we have discussed would be to anchor on a TEL which is anchored to the KEL of the original AID an attestation of what domain names are allowed as AKAs for that did:webs AID. This would be secure. Simply including an unanchored or otherwise unprotected AKA in a didDoc for some did:webs did does not protect one from a spoofing attack. When given a protected verifiable attestation as suggested, a trusted did:webs resolver can securely populate the AKA section of the didDoc with the other domain names or equivalently the other did:webs dids that all share the same AID but have different domains.

This attestation could be included in the keri.cesr file because CESR supports streaming of such attestations (as ACDCs) even when interleaved with key events and their attachments. Technically the attestation would be a type of ACDC with a schema that defines it as an attestation of AKAs for the did:webs dids allowed by the issuing aid.

The resolver just has to search for schema SAIDs that match the defined SAID for such attestations.

This could be extended to any type of data that we want to include in a did:webs didDoc that we want to have the security property of being anchored to key state. All the resolver has to know is the schema SAIDS of any attestations it is responsible for extracting from the keri.cesr file and then when it processes the keri.cesr file it can match and extract the associated attestations and populate the associated fields or blocks in the did:doc with highest class security according to the KERI way.

[2byrds]

From our meeting today:

• The domain is helpful for discovery but there is no guarantee that the controller has control of the domain it is hosted on for instance the did document on github.
• The controller only controls the unique (KERI AID) identifier
• If some one asserts a relationship between your AID and a domain (hosting a did:webs with your AID on their domain), it would be nice to be able to anchor what relationships you 'approve' (the domains you have chosen to host it).
• Related issue is your transition from domains over time (my university merged with another, the did:webs on both domains are equivalent)
• We recognize that domain names are not persistent

[2byrds]

Very useful @SmithSamuelM ! Thank you for tying the security characteristics concepts (Out-of-band associations, Anchoring, BADA-RUN, bare signatures) together based on our meeting discussion today regarding spoofed AIDs. I especially appreciate that you enumerated the options, so that I could compare the pros/cons of each solution!

[swcurran]

My understanding was that there is (is going to be?) a “KERI-way” event to indicate that DID associated to the did:webs location. My understanding was also that there would be a further way a way to say “Here is the new did:webs DID for this AID” that could be used to add an “AlsoKnownAs” entry into the DID for an old web location to be used in case of redirections, the merges of organizations, etc. — any situation where the controller wants to indicate the have deliberately moved the document.

[peacekeeper]

anchor on a TEL which is anchored to the KEL of the original AID an attestation of what domain names are allowed as AKAs

I know I missed the meeting today, but somehow I still don't get what's the spoofing attack described here or in #28.

If I create an AID 12345 that I control, and even if I manage to break into Coca Cola's servers and upload my did.json and keri.cesr such that did:webs:coca-cola.com:12345 (my AID on Coca Cola's servers) becomes resolvable and verifiable, so what?

1. Is the problem that people will look at the human-readable part of the DID and think that it's really Coca Cola --> Well if you rely on something like that, then you haven't really understood what DIDs are anyway. Especially if you have a bit of a KERI background, you should understand that the domain name is only for discovery and doesn't mean anything.

2. Is the problem that my did.json and keri.cesr will get deleted from the Coca Cola servers and I have to move my AID elsewhere? --> Well the assumption of KERI (and DIDs) is that the web is broken anyway and that this always happens eventually, so we need to deal with it in any case.

[2byrds]

We will discuss this and related issues at today's meeting

[2byrds]

The other issues/PRs related to equivalentId, alsoKnownAs, redirection using the designated aliases feature provides a strong additional layer of protection against spoofing,etc. Great conversation!