DID doc publisher should be under the authority of the AID controller(s) about tswg-did-method-webs-specification

[dhh1128]

I don't think we have this risk, if the KEL/TEL has to record the URL at which the KEL is published. Am I wrong?

[2byrds]

I don't think we have this risk, if the KEL/TEL has to record the URL at which the KEL is published. Am I wrong?

Yes, I agree that anchoring the did:webs to the KEL/TEL is a simple/thorough strategy. It looks like we have agreement in the group on that. So we'll add information about the events that support this.

IF in the future there will be other options as well, like a DID document published for discovery purposes and thus using the BADA RUN security characteristics.... then we need to document that for the reader so that they can understand the difference between the two, especially from a security PoV.

[peacekeeper]

Is this really a problem, if I publish somebody else's KERI event stream on my domain name?

What attacks or other problems can this possibly enable?

In pretty much any DID method, I can add somebody else's public keys into my DID document, so what, what's the harm? I can't prove control of the DID anyway, since I don't have the private keys.

[2byrds]

Is this really a problem, if I publish somebody else's KERI event stream on my domain name?

What attacks or other problems can this possibly enable?

In pretty much any DID method, I can add somebody else's public keys into my DID document, so what, what's the harm? I can't prove control of the DID anyway, since I don't have the private keys.

I believe there were two discussed goal, both relying on the did:webs document becoming non-verifiable if it is retrieved on an unsanctioned domain:

1. Domains carry associated meaning for most users. Therefore, the domain I choose to host my did:webs should be under my control (via verification) so that I can choose that association (domain). We are hopefully creating an internet with real identity verification where users can 'tune out' resources/sites/information that aren't verifiable. So if you recreate my did:webs identifier on your domain without my consent, no user who has the verification filter turned on will ever see it there.... Hopefully I'm not conflating concepts by adding that this seems similar to the checks my browser does with web certs and the domain of a website that i visit

2. We want to create a verifiable way to track the movement away from previously verifiable domains. That is related to number 1 but is more about tracking where I have chosen to host my did:webs over time. You used to be able to find my verifiable identifier hosted at domainOld but now it is hosted at domainNew.

Wondering a little more.... for verifications that are expensive (giant KELs/TELs that reference other giant KELs/TELs, etc), could an attacker force expensive verifications by creating did:webs documents that drive users to out-dated or incorrect information that takes significant resources to verify? I would want users/systems to know where they can find my sanctioned/most-up-to-date did:webs and I would choose a domain and associated infrastructure that is most reliable.

[swcurran]

IMHO — there is no problem with publishing a DID and all of it’s data on another web server. The “id” and any “alsoKnownAs” entries in the DIDDoc would not match the location of the DID, but there is not a problem.

The use of “id” and the ability to (in Web terms) redirect the discovery of the DIDDoc (etc.) to use another web location is so that after the redirection, DIDs that may exist in published documents anywhere in the world (e.g. in registries, verifiable credentials, and so on) that point to the old site can be seen verified on the new as being intentional synonyms defined by the controller.

Of course, that works fine if the web redirection is automatic. It doesn’t do so well if there is not a web redirection and the resolver has to use some other discovery technique. The AID and the KERI log enables verification wherever they are found.

[2byrds]

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

[2byrds]

Designated aliases feature as documented, handles the authority of the domain hosting the did:webs identifier