Closed kdenhartog closed 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"
}
}
]
@kdenhartog I'm satisfied thus far with @tplooker 's responses
Sounds good. I'll go ahead and close this PR for now then.
@llorllale @cywolf @tplooker I'm moving the discussion from the PR over here, so that the PR wouldn't linger.