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

Bob, Orie already provided one answer to your first question. A second
answer would be to use the did:web method
<https://w3c-ccg.github.io/did-method-web/>. That is one way to
associate a DID document with a URL (although the syntax currently supports
only a subset of URL syntax).

RE your second question—a general mechanism defined for discovering
whatever DIDs are associated with some non-DID resource such as an URL—that
is exactly what is already happening. The first example is The Decentralized
Identifier (DID) in the DNS
<https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns-05> spec. To
quote from the latest IETF draft:

   Decentralized Identifiers (DIDs) [W3C-DID
<https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns-05#ref-W3C-DID>]
use a Uniform Resource
   Identifier (URI) scheme [RFC3986
<https://datatracker.ietf.org/doc/html/rfc3986>] to identify persons,
organizations,
   or things in decentralized infrastructure, such as blockchains and
   distributed ledgers.

   DIDs are structured around "methods", each method defining the syntax
   of the "method specific identifier" and the operations on the
   respective DIDs (See Section 3.2 of [W3C-DID
<https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns-05#ref-W3C-DID>]
and [DID-METHODS
<https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns-05#ref-DID-METHODS>]).
   For many methods, the method specific identifier is not human-
   friendly (such as hash values, referring to transactions on a
   blockchain).  Most DIDs are therefore inherently hard to memorize for
   humans.

   By referring to DIDs from the Domain Name System (DNS), those hard to
   memorize identifiers can be discovered via well known, human friendly
   and widely established names.  This document specifies how DIDs can
   be published in the DNS for discovery on the base of host names and
   email addresses.


   Since DIDs use a URI scheme ('did'), this specification leverages the
   existing URI DNS Resource Record Type (RRType) [RFC7553
<https://datatracker.ietf.org/doc/html/rfc7553>].  Records
   are scoped using the '_did' global underscore node name, as described
   in Section 3.1
<https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns-05#section-3.1>.


A second example is that GLEIF is preparing to extend its registry services
for Legal Entity Identifiers (LEIs)
<https://en.wikipedia.org/wiki/Legal_Entity_Identifier> to enable discovery
(and verification) of the DID(s) associated with a LEI.

I am certain there will be more, simply because being able to prove the
association between a DID (as a cryptographically verifiable identifier)
and any other type of identifier adds value to both identifiers (and to
their controller).

Hope this helps,

=Drummond



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