hyperledger / aries-rfcs

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions
https://hyperledger.github.io/aries-rfcs/
Apache License 2.0
324 stars 218 forks source link

RFC 0067: How should DIDs be represented? #80

Closed kdenhartog closed 5 years ago

kdenhartog commented 5 years ago

@llorllale @cywolf @tplooker I'm moving the discussion from the PR over here, so that the PR wouldn't linger.

andrewwhitehead commented 5 years ago

@tplooker Re: https://github.com/hyperledger/aries-rfcs/pull/76#issuecomment-501498257

If routing keys present in the publicKeys section had a different controller DID then it would be simple enough to filter them out when creating the reverse index from verkey to connection. One complication is that I'm not sure there is always an appropriate DID to substitute for the controller – the routing agent may not have a public (ledger) DID, or the agent producing the DIDDoc may not know what that is, and they probably don't want to insert the DID used in their pairwise connection with the routing agent.

I don't mind the syntax that inserts the whole key definition instead of a literal verkey or a key reference. Is it reasonable to allow either a (string) reference or a (object) key definition for any of the recipient or routing keys? Or should there be an object equivalent of a key reference, ie. something like this (making the key ID and controller optional):

"service": [
  {
    "id": "did:example:123456789abcdefghi;did-communication",
    "type": "did-communication",
    "priority" : 0,
    "recipientKeys" : [
      {
        "ref": "did:example:123456789abcdefghi;#keys-1"
      }
    ],
    "routingKeys" : [
      {
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase64": "8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"
      }
    ],
    "serviceEndpoint" : "did:example:xd45fr567794lrzti67;did-communication"
  }
]

The DID spec also seems to allow a JSON-LD object for the service endpoint which might be an interesting option, I think it might resemble this:

"service": [
  {
    "id": "did:example:123456789abcdefghi;did-communication",
    "type": "did-communication",
    "priority": 0,
    "serviceEndpoint": {
      "@context": "did:<...>/didcomm",
      "recipientKeys": [
        {
          "ref": "did:example:123456789abcdefghi;#keys-1"
        }
      ],
      "routingKeys": [
        {
          "type": "Ed25519VerificationKey2018",
          "publicKeyBase64": "8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"
        }
      ],
      "url": "did:example:xd45fr567794lrzti67;did-communication"
    }
  }
]
llorllale commented 5 years ago

@kdenhartog I'm satisfied thus far with @tplooker 's responses

kdenhartog commented 5 years ago

Sounds good. I'll go ahead and close this PR for now then.