RFCs 0160, 0094, 0067: Differences between implementations and spec

[dbluhm]

While writing tests for the connection protocol in the test suite, I made a few observations regarding DID Documents as described in the DIDDoc conventions RFC and Cross domain messaging RFC and how those differ from some of the current implementations.

First off, the connection protocol doesn't actually make specific recommendations or requirements regarding what is expected in DID Documents even though the information contained therein is crucial to the successful parsing and processing of connection requests and responses. I wonder whether we should make some sort of recommendation by linking to the DIDDoc connection or another RFC where expected values (especially services) are outlined.

My second observation is closely related to the first. The DIDDoc convention and cross domain messaging RFCs describe or show examples of DID Documents where the service denoting the agent service uses a service type of did-communication and a service identifier suffixed with ;did-communication. However, I believe the Aries Cloud Agent Python and Aries Framework DotNet projects are successfully interoperating using IndyAgent as the service type and a service identifier suffix of ;indy.

So my question is where should we encourage change? I think usage of did-communication makes more sense given that we've now migrated from Indy Agent but I didn't want to "enforce" one practice or the other without first calling attention to the discrepancies.

@swcurran @tmarkovski @TelegramSam @dhh1128

[troyronda]

We have implemented DIDDoc convention in aries-framework-go using did-communication. https://github.com/hyperledger/aries-framework-go/pull/825

(also - I agree it makes more sense to have generic DIDComm names in the DIDComm protocols.)

[swcurran]

My opinion is that 0160 is the connection protocol, so that it should be the one takes priority amongst the three mentioned. That it does not align to 067 should be noted, and we must make sure that a future version of the connection protocol (which will be DID Exchange) is aligned with 067. I believe that is what I think Troy is saying the Go team has done. If we do have another version of the connection protocol before going to DID Exchange (which I doubt we will do), the 067 alignment should be included in the update.

0094 is a concept RFC and so should be updated to align with 067, but concept RFCs should be of less importance from an implementation perspective than features.

[dbluhm]

@swcurran the connection protocol doesn't make any specific recommendations on DIDDoc format, deliberately omitting those details, so there's nothing to align with 67.

[swcurran]

Got it. Sorry. I suggest we get whatever is being used in the implementations we have into 0160. We should do that without changing the version of the RFC. I'll get a PR in today.

[dbluhm]

My recommendation would be to make the more forward thinking did-communication be the expected service type and service identifier suffix and note that agents seeking to be backwards compatible can also include an additional service with type IndyAgent which follows the same rules. This would not be a major breaking change and gives implementations still using IndyAgent time to update.

[swcurran]

I would say that would be connections v1.1, wouldn't it? What we have today is 1.0.

[dbluhm]

Maybe... I have issues with something that was never explicitly Aries RFC Standard being suddenly introduced as standard, especially when other relevant RFCs at least indicate a different convention, if not standard. I'm willing to work those out on my own though lol if others prefer this approach.

[swcurran]

We're playing catch up on being able to tell people "this is what we are using", so that we have can have independent development and interop. My goal is to get a stake in the ground so that we can do that, and then we can move forward from there. Hence we define what has been de facto implemented as 1.0 documented, and move forward from there. We can have this marked as status archived as soon as we want, but that will still allow us to link to the version of the RFC in an Aries Stable document.

[swcurran]

FYI - here is an example DIDDoc from the current implementations:

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:sov:QUmsj7xwB82QAuuzfmvhAi",
  "publicKey": [
    {
      "id": "did:sov:QUmsj7xwB82QAuuzfmvhAi#1",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:sov:QUmsj7xwB82QAuuzfmvhAi",
      "publicKeyBase58": "DoDMNYwMrSN8ygGKabgz5fLA9aWV4Vi8SLX6CiyN2H4a"
    }
  ],
  "authentication": [
    {
      "type": "Ed25519SignatureAuthentication2018",
      "publicKey": "did:sov:QUmsj7xwB82QAuuzfmvhAi#1"
    }
  ],
  "service": [
    {
      "id": "did:sov:QUmsj7xwB82QAuuzfmvhAi;indy",
      "type": "IndyAgent",
      "priority": 0,
      "recipientKeys": [
        "DoDMNYwMrSN8ygGKabgz5fLA9aWV4Vi8SLX6CiyN2H4a"
      ],
      "serviceEndpoint": "http://192.168.65.3:8030"
    }
  ]
}

So my plan would be to add basically this to the existing RFC to clarify exactly what the DIDDoc referenced in the Message JSONs showed look like. I'll also compare that to what is in the 0067 to indicate if it is the same or different. It will be different, and I'll also highlight the anomalies in this - the use of "did:sov" and "IndyAgent".

[swcurran]

I've added an example DIDDoc to the connections RFC - #319 to try to address this.

Does that help?

[dbluhm]

@swcurran Yes, that helps. Thanks for taking the time to do that. I do hope we can quickly change to a more appropriate service type in the near future.

[andrewwhitehead]

Instead of ;did-communication in the service identifier, shouldn't it be #did-communication, or potentially any unique ID as long as the service type is correct?

I don't see any examples in the Decentralized Identifiers working draft following that syntax for identifiers, although the service endpoint might be referred to externally using the did:example:21tDAKCERh95uGgKbJNHYp;service=did-communication URI syntax.

[dbluhm]

I also noticed that today. RFC 67 shows #did-communication whereas RFC 94 shows ;did-communication. I also agree that the ID could be anything and shouldn't be forced to have an ID with #did-communication to identify a DID Comm service.

[TimoGlastra]

As this issue hasn't seen any activity on over two years I assume we can close it as we've moved away from most of the things discussed in this issue. If not, what do we need to do to close this issue?

I'll give it some time for people to respond, and will otherwise close.