Add did:3 processing, resolution processing, and some clarification on the rules

[swcurran]

Given that we want to support did:peer:3 as soon as the DID has been transmitted from the creating to the receiving agent, and by definition, all these DIDs have been transmitted, I think we should target did:peer:3 DIDs, with did:peer:2s as intermediaries. This addresses #2.

I tried to clarify a bit the wording around the if/else processing. It's messy regardless, but hopefully it's not worse :-). A diagram might be helpful, or overkill.

I added a resolution section on what to do on receipt of a DID to be found, whether it is an unqualified DID (expected as we transition from unqualified to qualified DIDs), a did:peer:2 (not really expected), or a did:peer:3.

There was discussion on the Aries Working Group call to move this content to an Appendix in this Community Coordinated Update. @TimoGlastra -- would you be open to that? Link to the Community Coordinated Update PR.

[swcurran]

@TimoGlastra -- any comments on this? Can you merge this? We're going to be talking about this on the Aries Working Group call today (July 26). Specifically:

• I think this PR is appropriate, so I'd like to get it merged. Or if not, let's talk about it.
• As noted above, I'd like to take this content and put it into the Community Coordinated Update. Are you OK with that?

Thanks!

[swcurran]

I'm going to be talking about two other things that should be decided that aren't referenced here:

• Should we convert ed25519 verification keys to x25519 keys and use both in the did:peer:2 so there is an explicit version of both? It doesn't really matter about the length since the outcome we want is the did:peer:3, but I think it is good practice that we are doing that in all cases vs. the old implicit approach.
• We have to decide on exactly the type for the service item -- IndyAgent (no! :-) ), did-communication, DIDCommMessaging. Again -- doesn't matter as long as we agree.

Also wondering -- I'm 95% sure that all ACA-Py DIDs are the same -- exactly one key, exactly one service endpoint. Are AFJ created DIDComm DIDDocs more flexible?