propose HIPE: Revised did doc conventions #92
Conversation
Signed-off-by: Tobias Looker <[email protected]>
tplooker
changed the title
tplooker
changed the title
Signed-off-by: Tobias Looker <[email protected]>
|
|
||
| Within the [DID Specification](https://w3c-ccg.github.io/did-spec/#did-documents) lies a section called [Service Endpoints](https://w3c-ccg.github.io/did-spec/#service-endpoints), this section of the DIDDoc is reserved for `any type of service the entity wishes to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction`. | ||
|
|
||
| This HIPE introduces the specification of a new DID service endpoint type called `IndyAgent`, which takes the following form. |
There was a problem hiding this comment.
I'd like to remove the Indy brand from the service endpoint type name. How about just "A2A"?
There was a problem hiding this comment.
@dhh1128 shall we park this until we have chatted with the community at the connectathon about how best to proceed, given the conversation we had to day around potentially elevating this protocol in general above agents?
There was a problem hiding this comment.
@dhh1128 I have changed this to DidMessaging for now as that is where I see the level of interop being distinguished.
| {"id": "6", "type": "RsaVerificationKey2018", "owner": "did:sov:1234abcd","publicKeyPem": "-----BEGIN PUBLIC A…"} | ||
| {"id": "3", "type": "RsaVerificationKey2018", "owner": "did:example:1234abcd","publicKeyPem": "-----BEGIN PUBLIC X…"}, | ||
| {"id": "4", "type": "RsaVerificationKey2018", "owner": "did:example:1234abcd","publicKeyPem": "-----BEGIN PUBLIC 9…"}, | ||
| {"id": "6", "type": "RsaVerificationKey2018", "owner": "did:example:1234abcd","publicKeyPem": "-----BEGIN PUBLIC A…"} | ||
| ], | ||
| "authentication": [ |
There was a problem hiding this comment.
Does anyone know what the "authentication" key distinction means semantically? Is it still a useful abstraction for DIDDocs?
| "id": "did:example:xd45fr567794lrzti67;indy-agent", | ||
| "type": "IndyAgent", | ||
| "priority" : 0, | ||
| "recipientKeys" : [ "did:example:xd45fr567794lrzti67#1" ], |
There was a problem hiding this comment.
Worth noting whether recipientKeys, mediatorKeys could be embedded; e.g.,
[
"did:example:xd45fr567794lrzti67#1",
{
"id": "did:example:xd45fr567794lrzti67#99",
"type": "Ed25519VerificationKey2018",
"controller": "did:example:xd45fr567794lrzti67",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
},
...
}
? I'm inclined to think they could be?
There was a problem hiding this comment.
@sklump, I can see your point however I don't think we will want to allow this behavior as it limits the utility of the key if it is specified inline.
| "priority" : 0, | ||
| "recipientKeys" : [ "did:example:1234abcd#4" ], | ||
| "mediatorKeys" : [ "did:example:1234abcd#3" ], | ||
| "serviceEndpoint" : "did:example:xd45fr567794lrzti67;indy-agent" |
There was a problem hiding this comment.
Where has DID xd45fr5677941rzti67 come from? How does the serviceEndpoint value resolve to a usable address? Could something here have a typo?
There was a problem hiding this comment.
@sklump This is pointing at the mediator agents r us's did doc, defined just below this did doc. This allows separation in the definition of the endpoint from individual using the endpoint. The message preparation example below the did doc definitions should describe this case, let me know if it is still not clear.
Signed-off-by: Tobias Looker <[email protected]>
Signed-off-by: Tobias Looker <[email protected]>
Signed-off-by: Tobias Looker <[email protected]>
|
|
||
| The HIPE requirement in those degenerate cases is that the DIDDoc still contain the same data (one endpoint, one `routing` key, one authentication key and at least one Receiver key). The domain implementation then handles the case of "Agents with multiple roles". The DIDDoc SHOULD have the Agents use different keys for different purposes to mask the simplified Agent structure. | ||
| 1. Alices agent resolves the above DID doc Bobs agent has shared with her and resolves the `DidMessaging` service definition. | ||
| 2. Alices agent then packs the desired message she wishes to trasmit with the keys noted in the `recipientKeys` array. |
| 4. The resulting message from the previous step is then packed for the first and only key in the `routingKeys` array. | ||
| `pack(wallet,wrapped_message,[did-resolve(did:example:1234abcd#3)],sender_verkey)` | ||
| 5. Resolution of the service endpoint leads to resolving another `DidMessaging` service definition, this time owned and controlled by `agents-r-us`. | ||
| 6. Because in the `agents-r-us` service definition there is a recipient key. The newly packed message is then wrapped in another forward to key message where the subject is first and only key in the `routingKeys` array. |
There was a problem hiding this comment.
These textual references to keys should include their respective URIs? I don't understand the semantics here. The routingKeys array is empty in the agents-r-us service definition, and the Alice has already wrapped the message for the key in the other routingKeys array in step #4.
Also, a sentence fragment starts at 'Because'.
| 5. Resolution of the service endpoint leads to resolving another `DidMessaging` service definition, this time owned and controlled by `agents-r-us`. | ||
| 6. Because in the `agents-r-us` service definition there is a recipient key. The newly packed message is then wrapped in another forward to key message where the subject is first and only key in the `routingKeys` array. | ||
| 7. This wrapped message is then packed in a message for the keys noted in the `recipientKeys` array of the `agents-r-us` `DidMessaging` service defintion. | ||
| 8. Finally as the endpoint listed in the serviceEndpoint field for the `agents-r-us` `DidMessaging` service definition is a valid endpoint URI, the message is tramitted in accordance with the URI's protocol. |
| @@ -34,7 +25,7 @@ These are vital design goals for this HIPE: | |||
| 1. **Sender Encapsulation**: We SHOULD minimize what the Receiver has to know about the domain (routing tree or agent infrastructure) of the Sender in order for them to communicate. | |||
| 2. **Receiver Encapsulation**: We SHOULD minimize what the Sender has to know about the domain (routing tree or agent infrastructure) of the Receiver in order for them to communicate. | |||
| 3. **Independent Keys**: Private signing keys SHOULD NOT be shared between agents; each agent SHOULD be separately identifiable for accounting and authorization/revocation purposes. | |||
| 4. ***Prevent correlation based on DIDDoc Contents**: The information in the set of DIDDocs owned by an Identity SHOULD NOT be so precise as to represent a fingerprint for that Identity suitable for correlation. | |||
| 4. **Prevent correlation based on DIDDoc Contents**: The information in the set of DIDDocs owned by an Identity SHOULD NOT be so precise as to represent a fingerprint for that Identity suitable for correlation. | |||
There was a problem hiding this comment.
Should this be either dropped or revised to reference public vs. local DIDDocs?
If the set of DIDDocs are local, you are sharing each with a limited set of parties - not publishing them publicly. Since the other parties don't know each other, and each likely has some deeper knowledge of who you are, does this issue matter? Put another way, with the details we are adding to the local DIDDocs, are we adhering to this?
If it is a public DIDDoc, it's unlikely that the controlling party is not known, as you can send a message to it and ask "who are you?" (and you might get an answer). It's also likely to be a minimal DIDDoc. Maybe revise this to say "The information in Public DIDDocs (published on a ledger) SHOULD NOT..."
|
This PR has been deprecated in place of a new proposal here |
Initial update to the diddoc conventions for routing via verkey.
I have shrunk this document to be more about only the did doc conventions. This creates less context when reading it on its own, but my preference would be for downstream documentation to point to this for greater context.
Signed-off-by: Tobias Looker [email protected]