Consider alsoKnownAs, equivalentId about tswg-did-method-webs-specification

[dhh1128]

I agree; in the sentence you quoted, equivalentId is probably what we want, not alsoKnownAs.

The other use of alsoKnownAs that was posited at one point was to declare the did:web equivalent of a did:webs. I think this usage is an antipattern and should not be mentioned, let alone recommended, in the spec.

[peacekeeper]

The other use of alsoKnownAs that was posited at one point was to declare the did:web equivalent of a did:webs. I think this usage is an antipattern and should not be mentioned, let alone recommended, in the spec.

Hmm why? I actually thought this was very useful, to use alsoKnownAs for listing the did:web, did:webs, and did:keri equivalents.

[dhh1128]

I don't think that it's necessary to specify did:keri equivalents, because they can be deduced trivially from the AID in did:webs. All DID methods, current and future, that declare a DID to be rooted in a given AID are by definition equivalents without declaring them so. That is, did:webs:abc.com:aid and did:keri:aid are equivalents by definition, and should be algorithmically deduced rather than depending on a declaration which may or may not be present. But maybe it's harmless; anyway, this wasn't really my concern.

My concern has to do with analyzing did:web and did:webs as "equivalents", because I think there are several ways to go wrong with that equivalence, semantically:

1. (This concern is only theoretical and could be hand waved around, maybe, since alsoKnownAs exposes only weak semantics. But I think we're encouraging pretty bad thinking...) Since did:web has no history, and did:webs does, I'm not sure how "equivalent" these two DID values really are. The did:web refers to a subject at the instant of resolution, and ONLY at the instant of resolution. You cannot reason about whether did:web referred to the same subject yesterday, or whether it will refer to the subject tomorrow, or what its key state ever has been or will be, since the same URL can be created and destroyed many times with different subjects (or with no subject at all, if it's used for a non-DID purpose) over the lifespan of the URL namespace. In other words, alsoKnownAs between did:web and did:webs is only known to be true to the did:webs author at the moment the DID doc is written, and is only assumed to be true to the did:web user at the moment the did:web is resolved. Hackers can play all sorts of games with this. People already make a fundamental concept error re. temporality when they use did:web as an issuer or holder of VCs, which depend on a stable DID subject; I fear they will have this error reinforced by saying that the did:webs is alsoKnownAs a did:web.

2. (also possibly something we could hand wave around) In a similar vein, these two DIDs have different controllers (did:web is controlled by whoever controls DNS and web publication infrastructure, and did:webs is controlled by cryptographic keys). This distinction is especially stark if a did:webs uses multisig, because it means that the DID doc returned by did:web resolution will be invalid. However, I admit that two DIDs with different controllers can be known as one another, if they identify the same subject, so maybe this controller difference isn't crucial.

3. I think we're being imprecise in our thinking about which direction the assertion works in the alsoKnownAs. When we get precise, its apparent usefulness shrinks or vanishes.

   Suppose, for a moment, that we analyze alsoKnownAs not as a feature of did:web, but rather as a feature of did:webs. (That would be natural, if we write about it in this spec.) In that case, we're asking the controller of the did:webs to assert something to the resolver's impl of did:webs. That's fine -- except that if we're talking about a client's did:webs implementation, which must validate against the KEL and TEL, the aka information would be in the TEL already. The client's impl of did:webs doesn't need the assertion.

   On the other hand, if we say that the information is for did:web clients, then we are inviting a security vulnerability in the assertion. A did:web DID doc that contains an alsoKnownAs may appear to have a signed .kel published per did:webs rules. However, since the did:web impl won't walk the KEL/TEL to prove it, the correctness of that assertion stands or falls on the security of DNS and the TLS session, and NOT on KERI. The alsoKnownAs section may have been created by mechanisms with KERI knowledge, but since the client will not validate with that knowledge, it becomes possible to be a webmaster to lie about the alsoKnownAs values in whatever did:webs their server hosts -- and unfairly tarnish the reputation of the did:webs in the process.

[2byrds]

Per our meeting today:
Lance will update his PR to include equivalentIds in the alsoKnownAs superset. The equivalentIds will only be did:webs AID controlled identifiers, specified in the designated aliases attestation.