DIDComm incompatible with Sidetree/ION

[nikolockenvitz]

It seems that a similar issue has already been discussed here in #294, but the fix in #352 doesn't solve the problem as far as I understand.

See https://github.com/decentralized-identity/sidetree/issues/1198 for further context, but the gist is that DIDComm now mandates usage of arrays for the serviceEndpoint field in a DID Document (Routing Protocol 2.0, see example from spec below)

{
    "id": "did:example:123456789abcdefghi#didcomm-1",
    "type": "DIDCommMessaging",
    "serviceEndpoint": [{
        "uri": "https://example.com/path",
        "accept": [
            "didcomm/v2",
            "didcomm/aip2;env=rfc587"
        ],
        "routingKeys": ["did:example:somemediator#somekey"]
    }]
}

However, Sidetree only allows URI strings and objects, but explicitly excludes arrays. See spec or implementation.

I raised this in Sidetree (https://github.com/decentralized-identity/sidetree/issues/1198) and they pointed out that their spec/implementation is compliant with the DID spec, which is technically correct. (DID spec says that serviceEndpoint must be URI, object, or array. Theirs is URI or object. Hence, everything ok.)

While I like to add array support to Sidetree/ION, I think DIDComm needs to support URIs and objects. Based on the previous reasoning, any DID method could only implement a subset of the allowed data types, so DIDComm must be able to work with all of them I'd say. Array support that was introduced via #352 is nice, but as fallback URI string and object should also work.

(Third option would be to change DID spec to require all DID methods to implement all three data types, but not sure how realistic this is)

[brianorwhatever]

I agree this should be changed to be more permissive and allow a service endpoint object. the DID spec does this all over so I don't think it's any more difficult for implementers

[TelegramSam]

Discussed WG 20230306 - Daniel proposed allowing a single object in addition to a set of objects. This would necessitate a dot release of the spec.

[nikolockenvitz]

Thanks @TelegramSam that would be great! Let me know if I can support with anything.