Sidetree doesn't allow array for serviceEndpoint property (incompatile with DIDComm)

[nikolockenvitz]

Hi, while trying to implement DIDComm, a colleague of mine noticed that there is a problem with Sidetree-/ION-based DIDs.

Context & Problem

In particular, the DIDComm messaging protocol demands an array for the serviceEndpoint field (in the service property of a DID document). In their spec, they provide the following example:

{
    "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, this does not align with the Sidetree specification, which does not allow arrays. Sidetree only allows strings (URIs) and JSON objects, but no arrays:

sidetree/docs/spec/patches.md

Line 145 in bcc0cdb

3. The object ****MUST**** include a `serviceEndpoint` property, and its value ****MUST**** be either a valid URI string (including a scheme segment: i.e. http://, git://) or a JSON object with properties that describe the Service Endpoint further. If the values do not adhere to these constraints, the entire _Patch Action_ ****MUST**** be discarded, without any of it being used to modify the DID's state.

But actually, the DIDComm spec is compliant with the current DID specification, because there it says that

The value of the serviceEndpoint property MUST be a string, a map, or a set composed of one or more strings and/or maps.
-- Decentralized Identifiers v1.0, 5.4 Services

As you can see, there is a mismatch between the DID spec and the Sidetree spec.

Requested Action

I think that Sidetree should also support arrays for the serviceEndpoint field and not discard corresponding PATCH actions (as the spec demands currently). Otherwise, Sidetree-based DID methods become unusable for protocols that build on top of the DID standard.

Any takes? Or does anyone know a good workaround how to use DIDComm with Sidetree-based DID methods (e.g. ION)?

[csuwildcat]

To be fair, the DID Core spec does not specify that all implementations MUST support all of those forms, and the reason Sidetree doesn't is because arrays were not yet allowed by the spec when Sidetree was specified. In point of fact, Sidetree's frustration about that was what motivated the DID Core spec to include arrays. Further, the DID Core spec notes that it is up to implementers to specify almost everything about the shape and content of these entries.

[nikolockenvitz]

You are right. It does not seem to be required to support all those forms and based on the test suite, ION is flagged as compliant there.

However, I am not sure whether that makes so much sense. If any DID method can pick only some types, then any protocol on top needs to account for all possible ways how a DID method could implement that. In the concrete use case, DIDComm would need to specify how the service endpoint could be encoded as a string, how as an object, and how as an array.

Anyway, do I understand you correctly that you would in general be open to also support arrays in Sidetree? If so, what's the process of updating spec/implementation? I will gladly create PRs.

[csuwildcat]

We'd be happy to have your contribution to enable array support in Service Endpoints. The process for doing so would include:

1. Update the Sidetree spec to include the necessary text describing the additional value type.
2. Update the implementation to include code for handling the change.
3. Rev the minor version to signify the introduction of a breaking change nodes need to upgrade to support.
4. Have the Sidetree WG send notice to consumers of the reference implementation to ensure they understand the implications of updating

I can work with you to help you through this, if you'd like.

[nikolockenvitz]

Thanks @csuwildcat, sounds great! Will open PR for spec and implementation soon. I expect the changes to be more or less straight forward. Will come back to you for review and deployment/publishing.