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

Drummond,
Thanks for your response. I understand that a backlink would provide a
useful verification mechanism, and I can see how I would create such a
backlink in a DID document. However, I'm asking about the case where the
alsoKnownAs <https://www.w3.org/TR/did-core/#dfn-alsoknownas> value is an
URL, not either a DID or DID URL, and thus I have no immediately obvious
DID document to inspect. In that case, how do I form the desired backlink
and where do I put it? It seems to me that I would need a way to resolve an
URL into either a DID or a DID document, but I can't find any such
mechanism defined in the spec. My assumption is that it would probably be
reasonable to do something like include a DID or DID document as a resource
served via WebFinger <https://datatracker.ietf.org/doc/html/rfc7033> -- if
my site supported WebFinger... Would that be considered reasonable? Is
there a better way to resolve an URL into either a DID or a DID document?

This leads to a second question: Is there a general mechanism defined for
discovering whatever DIDs are associated with some non-DID resource such as
an URL? For instance, given an URL like "https://example.com," what
mechanism could I use to search for all DIDs, DID URLs, or DID documents
that are associated with that URL?

bob wyman


On Wed, Sep 1, 2021 at 4:35 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
>>
>>
>>