Fix the Service's structure of DIDCommMessaging

[FabioPinheiro]

Minor fix on the DID document Service's structure for the type DIDCommMessaging.

The serviceEndpoint MUST be a json object with the fields uri, accept and routingKeys

---

Preview | Diff

[msporny]

New DID Method review volunteers, please review this change request.

/cc @apuchitnis @stenreijers @gatemezing @esaung @michallis @richardwinputra @adam-burns @Steffytan @MizukiSonoko @rajivrajani @genaris @harleyjackthomas @ajile-in @KDean-Dolphin

[genaris]

I think we should clarify in the spec if it is mandatory to encode serviceEndpoint as an array, or if it's possible to define it as an object in case of a single entry.

[genaris]

Current DIDComm V2 spec says that serviceEndpoint MUST contain an ordered list of objects.. This makes me think that, if you have a single endpoint, you'll need to define it as a list containing this single object.

However, in this example (and also Peer DID method specification), serviceEndpoint is encoded as an object.

[genaris]

I'm sorry, I was looking at DIDComm v2.0 but the latest stable version is v2.1, which allows for the encoding of an object. That explains why all other specs were 'wrong' :D

[genaris]

Not exactly related to this PR, but I think it's worth noting that this URL returns 404. It seems this issue was addressed some time ago (see decentralized-identity/didcomm.org#9) but somehow the link is broken again.

BTW the context file located at https://github.com/decentralized-identity/didcomm.org/blob/main/docs/messaging/contexts/v2/index.json seems to be using the old format.