Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DIDComm incompatible with Sidetree/ION #410

Open
nikolockenvitz opened this issue Sep 19, 2022 · 3 comments
Open

DIDComm incompatible with Sidetree/ION #410

nikolockenvitz opened this issue Sep 19, 2022 · 3 comments

Comments

@nikolockenvitz
Copy link

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 decentralized-identity/sidetree#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 (decentralized-identity/sidetree#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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants