feat: Update peer-did creation and resolution inline with …

[hamada147]

Overview

https://identity.foundation/peer-did-method-spec

This PR updates the library to align with the latest specifications for creating and resolving peer DIDs. It ensures compatibility with current and new methods of specifying the service field in a peer DID.

The PR accommodates two formats for defining the service field in the peer DID creation process. The first format is as follows:

{
	"type": "DIDCommMessaging",
	"serviceEndpoint": "https://example.com/endpoint1",
	"routingKeys": ["did:example:somemediator#somekey1"],
	"accept": ["didcomm/v2", "didcomm/aip2;env=rfc587"]
}

Using this format, a peer DID similar to the one below is created:

did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9lbmRwb2ludDEiLCJyIjpbImRpZDpleGFtcGxlOnNvbWVtZWRpYXRvciNzb21la2V5MSJdLCJhIjpbImRpZGNvbW0vdjIiLCJkaWRjb21tL2FpcDI7ZW52PXJmYzU4NyJdfQ

The second format, as per the new peer DID spec, is as follows:

{
  "type": "DIDCommMessaging",
  "serviceEndpoint": {
    "uri": "https://example.com/endpoint1",
    "routingKeys": [
      "did:example:somemediator#somekey1"
    ],
    "accept": [
      "didcomm/v2",
      "didcomm/aip2;env=rfc587"
    ]
  }
}

This results in a peer DID like this:

did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vZW5kcG9pbnQxIiwiciI6WyJkaWQ6ZXhhbXBsZTpzb21lbWVkaWF0b3Ijc29tZWtleTEiXSwiYSI6WyJkaWRjb21tL3YyIiwiZGlkY29tbS9haXAyO2Vudj1yZmM1ODciXX19

In both cases, the resolution of the peer DID will conform to the new peer DID specification, producing a resolved DID document similar to the following:

{
  "id": "did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vZW5kcG9pbnQxIiwiciI6WyJkaWQ6ZXhhbXBsZTpzb21lbWVkaWF0b3Ijc29tZWtleTEiXSwiYSI6WyJkaWRjb21tL3YyIiwiZGlkY29tbS9haXAyO2Vudj1yZmM1ODciXX19",
  "authentication": [
    {
      "id": "did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vZW5kcG9pbnQxIiwiciI6WyJkaWQ6ZXhhbXBsZTpzb21lbWVkaWF0b3Ijc29tZWtleTEiXSwiYSI6WyJkaWRjb21tL3YyIiwiZGlkY29tbS9haXAyO2Vudj1yZmM1ODciXX19#key-2",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vZW5kcG9pbnQxIiwiciI6WyJkaWQ6ZXhhbXBsZTpzb21lbWVkaWF0b3Ijc29tZWtleTEiXSwiYSI6WyJkaWRjb21tL3YyIiwiZGlkY29tbS9haXAyO2Vudj1yZmM1ODciXX19",
      "publicKeyMultibase": "z6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V"
    }
  ],
  "keyAgreement": [
    {
      "id": "did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vZW5kcG9pbnQxIiwiciI6WyJkaWQ6ZXhhbXBsZTpzb21lbWVkaWF0b3Ijc29tZWtleTEiXSwiYSI6WyJkaWRjb21tL3YyIiwiZGlkY29tbS9haXAyO2Vudj1yZmM1ODciXX19#key-1",
      "type": "X25519KeyAgreementKey2020",
      "controller": "did:peer:2.Ez6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud.Vz6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vZW5kcG9pbnQxIiwiciI6WyJkaWQ6ZXhhbXBsZTpzb21lbWVkaWF0b3Ijc29tZWtleTEiXSwiYSI6WyJkaWRjb21tL3YyIiwiZGlkY29tbS9haXAyO2Vudj1yZmM1ODciXX19",
      "publicKeyMultibase": "z6LSpSrLxbAhg2SHwKk7kwpsH7DM7QjFS5iK6qP87eViohud"
    }
  ],
  "service": [
    {
      "id": "#service",
      "type": "DIDCommMessaging",
      "serviceEndpoint": {
        "uri": "https://example.com/endpoint1",
        "routingKeys": [
          "did:example:somemediator#somekey1"
        ],
        "accept": [
          "didcomm/v2",
          "didcomm/aip2;env=rfc587"
        ]
      }
    }
  ]
}

Tests have been added and updated to support both described cases, ensuring that the peer DID creation and resolution process aligns with the new peer DID specification.

Fixes #

Checklist

My PR contains...

• No code changes (changes to documentation, CI, metadata, etc.)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes
• are not breaking changes
• If yes to above: I have updated the documentation accordingly

Documentation

• My changes do not require a change to the project documentation
• My changes require a change to the project documentation
• If yes to above: I have updated the documentation accordingly

Tests

• My changes can not or do not need to be tested
• My changes can and should be tested by unit and/or integration tests
• If yes to above: I have added tests to cover my changes
• If yes to above: I have taken care to cover edge cases in my tests

[github-actions]

Unit Test Results

96 tests   96 ✅  1s ⏱️
 9 suites   0 💤
 9 files     0 ❌

Results for commit 51122cf.

[FabioPinheiro]

LGTM (assuming there are no logical changes that the work done by @mineme0110 to fix the other lib)

[FabioPinheiro]

Suggested change

	"id": "did:peer:0z6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V#",
	"id": "did:peer:0z6MkqRYqQiSgvZQdnBytw86Qbs2ZWUkGv22od935YF4s8M7V#key-1",

[FabioPinheiro]

Can we merge this?