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

Bob,

The spec controlling the resolved resource (https://example.com) would need
to acknowledge how to verify the bi-directional link.

It's not defined in did core, since did core defines documents and methods,
however...

You could write a spec / update schema.org to handle a JSON-LD snippet that
could help with this, similar to:

https://schema.org/sameAs

Or:

https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource

Regards,

OS



On Wed, Sep 1, 2021 at 5:02 PM Bob Wyman <bob@wyman.us> wrote:

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

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>