Re: Verification of alsoKnownAs which is an URL, not a DID

Tom's right on this one. It's one of the reasons I never got the value of the alsoKnownAs property and largely feel it is likely an unfortunate attack vector.

It depends on what determines the value of the alsoKnownAs property.

If it is a mathematical certainty, e.g., the alias can be generated through deterministic formula, then there is no third party to trust. But it also is unnecessary. As the alias can be independently verified.

If it is a provable certainty, perhaps using "on chain" information from a decentralized registry, then the alsoKnownAsis procedurally deterministic and all one has to trust is the algorithm implemented by the registry. PoW, POS, and Byzantine Fault Tolerant systems, all purport to have solved this distributed consensus. This is how "follow the tip" let's you trust bitcoin for CRUD operations on a BTCR DID: you trust subsequent UTXOs because they link the CRUD operations deterministically to the current key material. In this case, you don't need a third party to evaluate the equivalence, because it is auditable by inspecting the chain. You might need to run a full node (or at least download the entire chain), but it is independently verifiable.

If it is neither mathematically nor procedurally deterministic, then you are relying on some trusted oracle. They may call themselves a "resolver" and they may promise to give you accurate DID Documents, but unless there is an ability to independently verify the assertion, you're simply introducing the resolver as a trusted authority. Reputation systems will help with this, but using a third party resolver necessarily introduces a trust relationship. If the resolver injects bogus alsoKnownAs properties, there's no way to tell. Just as there is no way to tell if they insert bogus key material in that same DID Document.

Run your own resolver. On your own terms.

And never trust alsoKnownAs if you can't independently verify the correlation.

If you *want* to rely on third party attestations that did:example:abc is equivalent to did:example:xyz, use a VC. That's not a hard statement to engineer. And in most use cases, solves the problem without relying on a trusted third party.

-j

On Wed, Sep 1, 2021, at 1:51 PM, Tom Jones wrote:
> The problem with all that is the source of the aka. When it appears in a resolution doc that is entirely under the control of the did method not the user.
> 
> thx ..Tom (mobile)
> 
> On Wed, Sep 1, 2021, 1:41 PM Drummond Reed <drummond.reed@evernym.com> wrote:
>> Bob: saying your concern is "misplaced" might be too strong, however alsoKnownAs does not introduce any new impersonation attack vectors that don't already exist with any other type of redirect mechanism on the web today. For example, it is trivial for me to create:
>> 
>>> http://my-domain.com/my-page
>> 
>> and program that webserver (which is completely under my control) to redirect that link to:
>> 
>>> http://your-domain.com/your-page
>> 
>> which is completely under your control. If a user who clicks on the first link does not notice that it redirects to the second, that user may be fooled into believing that I control the second resource.
>> 
>> The most common mechanism for mitigating this type of trivial impersonation attempt is to verify that the second resource includes a backlink to the first one, thus proving that the same party controls both resources. This is the mechanism we recommend in the note (copied below) that we put immediately after the definition of the alsoKnownAs property <https://www.w3.org/TR/did-core/#also-known-as>, and to which also we also refer in subsection 9.14 <https://www.w3.org/TR/did-core/#equivalence-properties> of Security Considerations.
>> 
>>> *NOTE**: Equivalence and alsoKnownAs*
>>> Applications might choose to consider two identifiers related by `alsoKnownAs <https://www.w3.org/TR/did-core/#dfn-alsoknownas>` to be equivalent *if* the `alsoKnownAs <https://www.w3.org/TR/did-core/#dfn-alsoknownas>` relationship is reciprocated in the reverse direction. It is best practice *not* to consider them equivalent in the absence of this inverse relationship. In other words, the presence of an `alsoKnownAs <https://www.w3.org/TR/did-core/#dfn-alsoknownas>` assertion does not prove that this assertion is true. Therefore, it is strongly advised that a requesting party obtain independent verification of an `alsoKnownAs` assertion.
>>> Given that the DID subject <https://www.w3.org/TR/did-core/#dfn-did-subjects> might use different identifiers for different purposes, an expectation of strong equivalence between the two identifiers, or merging the information of the two corresponding DID documents <https://www.w3.org/TR/did-core/#dfn-did-documents>, is not necessarily appropriate, *even with* a reciprocal relationship.
>> 
>> Hope this helps,
>> 
>> =Drummond 
>> 
>> 
>> 
>> On Wed, Sep 1, 2021 at 1:04 PM Bob Wyman <bob@wyman.us> wrote:
>>> The DID V1. spec <https://www.w3.org/TR/did-core/> says:
>>>> it is strongly advised that a requesting party obtain independent verification of an `alsoKnownAs` assertion.
>>> Given an alsoKnownAs value which is an URL, not a DID, (i.e. something like alsoKnownAs": ["https://myblog.example/"]), what mechanisms exist to do such an "independent verification?"
>>> 
>>> I am concerned about the possibility that an alsoKnownAs could be used to "impersonate," without authorization, the controller of some web resource that has no associated DID document. Is this concern misplaced?
>>> 
>>> bob wyman
>>> 
>>> 

--
Joe Andrieu, PMP                                                                              joe@legreq.com
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com <http://www.legendaryrequirements.com/>