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

also worth noting that:

https://www.w3.org/TR/did-core/#dfn-equivalentid
https://www.w3.org/TR/did-core/#dfn-canonicalid

Are controlled by the DID Method (which you already have to trust)...
whereas alsoKnownAs is controlled by the did controller (who you should not
trust without credentials)... See also

https://www.w3.org/TR/did-core/#equivalence-properties (As Drummond noted
above).

The did controller can always claim to be alsoKnownAs another identifier...
just like you can claim to be a person who is over 18 and has a different
name, even without presenting fraudulent credentials...

Same issue arises with services.... A controller can claim any web server
is their "preferred agent / inbox, etc..."... If you have a naive bot
crawling the verifiable data registry and attempting to connect to all
services you might even be able to use this as an amplification denial of
service attack, by creating many DIDs and registering a victim web origin
or ip as the service for each of them, resulting in a unique attempt to
connect per DID.

long story short... don't put anything but keys or verification material in
your did document... and don't trust anything a controller put in a did
document unless you have a credential or  "other reason" to trust the
entries are safe to use.

OS





On Wed, Sep 1, 2021 at 4:35 PM Joe Andrieu <joe@legreq.com> wrote:

> Tom's right on this one. It's one of the reasons I never got the value of
> the alsoKnownAs property and largely feel it is likely an unfortunate
> attack vector.
>
> It depends on what determines the value of the alsoKnownAs property.
>
> If it is a mathematical certainty, e.g., the alias can be generated
> through deterministic formula, then there is no third party to trust. But
> it also is unnecessary. As the alias can be independently verified.
>
> If it is a provable certainty, perhaps using "on chain" information from a
> decentralized registry, then the alsoKnownAsis procedurally deterministic
> and all one has to trust is the algorithm implemented by the registry. PoW,
> POS, and Byzantine Fault Tolerant systems, all purport to have solved this
> distributed consensus. This is how "follow the tip" let's you trust bitcoin
> for CRUD operations on a BTCR DID: you trust subsequent UTXOs because they
> link the CRUD operations deterministically to the current key material. In
> this case, you don't need a third party to evaluate the equivalence,
> because it is auditable by inspecting the chain. You might need to run a
> full node (or at least download the entire chain), but it is independently
> verifiable.
>
> If it is neither mathematically nor procedurally deterministic, then you
> are relying on some trusted oracle. They may call themselves a "resolver"
> and they may promise to give you accurate DID Documents, but unless there
> is an ability to independently verify the assertion, you're simply
> introducing the resolver as a trusted authority. Reputation systems will
> help with this, but using a third party resolver necessarily introduces a
> trust relationship. If the resolver injects bogus alsoKnownAs properties,
> there's no way to tell. Just as there is no way to tell if they insert
> bogus key material in that same DID Document.
>
> Run your own resolver. On your own terms.
>
> And never trust alsoKnownAs if you can't independently verify the
> correlation.
>
> If you *want* to rely on third party attestations that did:example:abc is
> equivalent to did:example:xyz, use a VC. That's not a hard statement to
> engineer. And in most use cases, solves the problem without relying on a
> trusted third party.
>
> -j
>
> On Wed, Sep 1, 2021, at 1:51 PM, Tom Jones wrote:
>
> 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
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>

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

<https://www.transmute.industries>