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

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