KERI event stream - detail KEL/TEL events for anchoring AlsoKnownAs, EquivalentID, and other DID metadata

[2byrds]

We need a way to say how "AlsoKnowAs" values are injected into the KEL/TEL, included in the end states of those, and then put into the DIDDoc. The ones we care about are when a did:webs is redirected to a new URL by its controller, so that existing references to the "old" DID are not useless.

[peacekeeper]

Yes we need to talk a bit more about alsoKnownAs (see also #11), but in general I find it a bit difficult to ask "what KEL/TEL events do you need in order to create a certain property in the DID document". The alsoKnownAs property is a good case where this question is difficult. I imagine that there will ALWAYS be an alsoKnownAs that points to the did:keri equivalent of did:webs. There is no explicit event that you need to generate in order to anchor this alsoKnownAs entry. It's simply there because the spec says so. So I think the better question is to ask "how is the KEL/TEL mapped to a DID document", and from that it follows what kind of events result in what kind of changes in the DID document.

[swcurran]

I think we want to explicitly support having a “did:webs” that is (web-terms) redirected to another URL. That is the specific use case for an event related to alsoKnownAs — allowing the controller to say that this was an intended event.

I think that is important, although I think I could be convinced otherwise :-)

[2byrds]

I need to add examples from the reference implementation of designated aliases

[2byrds]

Fixed in https://github.com/trustoverip/tswg-did-method-webs-specification/pulls