fix: did:peer:2 creation and parsing

[genaris]

Changes in did:peer:2 creation and parsing as specified in https://identity.foundation/peer-did-method-spec/#method-2-multiple-inception-key-without-doc. Basically:

• When creating did:peer:2, encode multiple services separately (i.e. in concatenated 'S' tokens instead of a single token containing the list). Verification methods are named using '#key-N' pattern and ordered
• When resolving a did:peer:2, name verification methods with the pattern "did#key-N" rather than "did#fingerprint"

I need to add some more tests and use cases check if it might represent an issue with AFJ 0.4.2 (apparently not).

Closes #1682

[genaris]

I think this will fail in case of >= 10 keys within a did:peer, so we should use a regex/remove '#key-' prefix and do the sorting numerically

[TimoGlastra]

Aren't the keys already sorted by default? I think we always process them start to end right?

[genaris]

Given that our input is a modeled DidDocument, In didDocumentToNumAlgo2Did() we are sorting by key purpose (first assertionMethods, then keyAgreement, authentication, etc.), so it might happen that a key referenced by a service will not be encoded in the order we expect (e.g. mixing up verification key and key agreement key, or using key from another service). This is mainly the reason for this concern.

[TimoGlastra]

@genaris any big changes still needed for this PR?

[genaris]

@genaris any big changes still needed for this PR?

I think there are no more changes needed from my side, unless we find a better way of handling these changes in the spec. I don't like so much the idea of limiting the key ids to the pattern 'key-N' (any call an existing app makes to agent.dids.create() for did:peer:2 not taking this into consideration will fail), but given the current state I think it safer to do so instead of doing some 'smart transformation' within did peer creation process (e.g. turning any key from input DidDocument into 'key-N' and make sure every reference to it is updated accordingly).

[TimoGlastra]

e.g. turning any key from input DidDocument into 'key-N' and make sure every reference to it is updated accordingly

Agreed. I've had this with several other did methods though, and it may be interesting to look at a better did builder pattern so you can input what type of did doc you want and the did registrar turns it into something compatible with the method.

E.g. i want two verificationMethods, one with keyType ed25519, the other one with this specific key. And most fields will just be optional and populated later on.

[TimoGlastra]

Might be better/cleaner to use parseDid here?