universal resolver does not return the same format as aca-py native resolve functionality

[martinMustermann]

I tried to resolve this DID 'did:sov:idu:6iHBriJn1DVJt3AjLEuHYL' in https://dev.uniresolver.io/ (like this https://dev.uniresolver.io/1.0/identifiers/did%3Asov%3Aidu%3A6iHBriJn1DVJt3AjLEuHYL) and I get a DIDDoc response.

And on the other hand, I set up an aca-py agent on IDunion and try to resolve the same DID as above (did:sov:6iHBriJn1DVJt3AjLEuHYL) and I get the following response back:

{ "@context":[ "https://www.w3.org/ns/did/v1" ], "id":"did:sov:6iHBriJn1DVJt3AjLEuHYL", "verificationMethod":[ { "id":"did:sov:6iHBriJn1DVJt3AjLEuHYL#key-1", "type":"Ed25519VerificationKey2018", "controller":"did:sov:6iHBriJn1DVJt3AjLEuHYL", "publicKeyBase58":"47ZPLULpKFGmeHLn8bbpVBzorKQwkgj1RA35Qu7h7bE5" } ], "authentication":[ "did:sov:6iHBriJn1DVJt3AjLEuHYL#key-1" ], "assertionMethod":[ "did:sov:6iHBriJn1DVJt3AjLEuHYL#key-1" ], "service":[ { "id":"did:sov:6iHBriJn1DVJt3AjLEuHYL#did-communication", "type":"did-communication", "serviceEndpoint":"https://bpa-acapy.int.eu.spherity.io", "recipientKeys":[ "did:sov:6iHBriJn1DVJt3AjLEuHYL#key-1" ], "routingKeys":[ ], "priority":1 }, { "id":"did:sov:6iHBriJn1DVJt3AjLEuHYL#profile", "type":"profile", "serviceEndpoint":"https://bpa.int.eu.spherity.io/profile.jsonld" } ] }

As you can see the DIDs are same so they are actually pointing to the same entity. However the content of the DIDDoc are different, and the most critical part of the difference is, in the service section, the universal resolver returns two more blocks, which does not contain property 'id'. And because of that, when I am trying to use this DIDDoc for creating a connection via endpoint '/didexchange/create-request', the aca-py cant parse the DIDDoc and will throw error (field 'id' is required).

Here I think there are some problems with DIDDoc formatting in universal resolver.

[peacekeeper]

Thanks.. The Universal Resolver resolves did:sov using the corresponding driver (uni-resolver-driver-did-sov).

As far as I know the latest specification is https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html.

I'd need more time to analyze whether the spec, or the Universal Resolver driver, or the aca-py implementation is the problem here. Do you have any insight into this?

As a separate note, Universal Resolver drivers should preferably re-use existing tools rather than implement DID methods themselves. So we could replace the current Universal Resolver did:sov driver with a thin wrapper around aca-py.

[swcurran]

We'll dig into the ACA-Py resolution. @peacekeeper is correct that the correct response should be based on the latest DID Method specification for did:sov, and that should include a "proper" DIDComm Service Endpoint.

@andrewwhitehead -- could you please take a look at what is in the ACA-Py implementation.

Thanks

[solidnerd]

@peacekeeper @martinMustermann @swcurran The reason why we have here two service endpoints is that the Bosch Business Partner Agent using an own concept called Public Profile. So this is a more specific problem to the BPA and other implementations. Since the BPA also leverages the ACaPy under the hood. It's more interesting now how to solve this with different Controllers or Agents and the problem of resolving it.

[mujtabaidrees94]

@solidnerd Interestingly enough the BPA's public profile endpoint is successfully returned by ACA-Py.
@swcurran The way I see it there are two issues here:

1. ACA-Py does not provide all the service objects which universal resolver does.
2. ACA-Py returns an extra id field, which is not part of latest specification. It also relies on this field in didexchange endpoint so if we resolve the DID Document via universal resolver the didexchange functionality throws exceptions.

The exception occurs when we try to call this endpoint /didexchange/create-request. In this case we are using universal resolver plugin with ACA-Py. As explained above, due to the different response format (i.e. missing id field) an exception is raised in ACA-Py.

Here are steps to reproduce this issue for better understanding:
1. Run ACA-Py with universal resolver plugin:

docker run --entrypoint "/bin/sh" --name aries-uni-resolver -p 8030:8030 -p 8031:8031 -dit bcgovimages/aries-cloudagent:py36-1.16-1_0.7.0

docker exec -it aries-uni-resolver bash

pip install git+https://github.com/sicpa-dlab/acapy-resolver-universal.git

aca-py start --auto-provision --auto-accept-invites --auto-accept-requests --auto-respond-credential-proposal --auto-respond-credential-offer --auto-respond-credential-request --auto-respond-presentation-proposal --auto-respond-presentation-request --auto-respond-messages --auto-store-credential --auto-verify-presentation --auto-ping-connection --monitor-ping --public-invites --plugin "aries_cloudagent.messaging.jsonld" --outbound-transport http --wallet-type "indy" --log-level info --inbound-transport http "0.0.0.0" 8030 --genesis-url "https://indy-test.bosch-digital.de/genesis" --endpoint https://cb4b-88-128-88-142.ngrok.io --wallet-name "wallet_db" --wallet-key "key" --admin "0.0.0.0" 8031 --label "aca-py agent" --debug-presentations --admin-insecure-mode --read-only-ledger --plugin universal_resolver

2. Then call this endpoint using swagger /didexchange/create-request with any cross-ledger indy based DID. In this case we use the above mentioned DID (did:sov:idu:6iHBriJn1DVJt3AjLEuHYL). The following exception occurs:

ValueError: Failed to deserialize DIDDocumentRoot:
2 validation errors for ParsingModel[DIDDocumentRoot]
__root__ -> service -> 0 -> id
  field required (type=value_error.missing)
__root__ -> service -> 3 -> id
  field required (type=value_error.missing)

This exception does not occur when we are using classic ACA-Py (without universal resolver plugin) as the response of DID resolution contains the id field.