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

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