Proposes the DIDComm RPC Protocol for App Attestation and more #804
Conversation
Signed-off-by: Stephen Curran <[email protected]>
Signed-off-by: Stephen Curran <[email protected]>
features/0804-didcomm-rpc/README.md
Outdated
| - `headers` -- optional, a JSON array typically used for conveying HTTP headers to be used in the processing of an HTTP URL `request_type`. As with all parts of this protocol, the meaning is up to the participants of an instance of the protocol. | ||
| - Each element of the array is an object with two elements: `{"name": "<header-name>", "value": "<header-value>"}`. | ||
| - When a `body` is included, a **required** element in the array is `"name": "Content-Type"` with the `"value"` being the `body`'s [MIME Type] (also know as the media type). | ||
| - `body.base64` -- optional, the [Base64 encoded] body of the request. |
There was a problem hiding this comment.
Should we allow the request to be attached as an attachment. Then it supports json + base64 + optionally signing in the future
features/0804-didcomm-rpc/README.md
Outdated
| - `request_type` -- **required**, an identifier indicating the type of the request. The value could be a URI, such as an HTTP URL, that the `sender` would like `responder` to resolve, or the value could be just a string understood by the `responder`. | ||
| - `headers` -- optional, a JSON array typically used for conveying HTTP headers to be used in the processing of an HTTP URL `request_type`. As with all parts of this protocol, the meaning is up to the participants of an instance of the protocol. | ||
| - Each element of the array is an object with two elements: `{"name": "<header-name>", "value": "<header-value>"}`. | ||
| - When a `body` is included, a **required** element in the array is `"name": "Content-Type"` with the `"value"` being the `body`'s [MIME Type] (also know as the media type). |
There was a problem hiding this comment.
I think this could also be solved by making the request payload an attachment
features/0804-didcomm-rpc/README.md
Outdated
| - `@type` -- required, must be as above | ||
| - `@id` -- required, must be as defined in [RFC 0005 DIDComm] | ||
| - `request_type` -- **required**, an identifier indicating the type of the request. The value could be a URI, such as an HTTP URL, that the `sender` would like `responder` to resolve, or the value could be just a string understood by the `responder`. | ||
| - `headers` -- optional, a JSON array typically used for conveying HTTP headers to be used in the processing of an HTTP URL `request_type`. As with all parts of this protocol, the meaning is up to the participants of an instance of the protocol. |
There was a problem hiding this comment.
I think RPC has no need to be related to HTTP style headers. Besides content type, do you have specific needs for this? We can solve that part with attachments, and we could then just make this part of the body. So if you need headers, we make it part of the body?
|
This comment is specific to the use case of app attestation and not the actual protocol. There are some emerging OpenID (driven by EUDI and the EU ARF) standards in this space that might be useful to review. The standard includes both the issuance of attestation credentials and a device binding (authentication) for high assurance use cases:
|
|
Suggestions from the discussion at the Aries Working Group call 20231216:
We’ll consider the suggestions to this protocol and provide an update with discussion of the changes. As to the App Attestation protocol — we’ll look at that, but would like more community feedback on the current implementation (based on Thanks for the feedback! |
|
Revamped the protocol to use JSON-RPC -- what a great idea!!! Makes the protocol much cleaner and easier, building on the shoulders of that specification. We did look at gRPC but found it to be too heavy weight for this purpose -- too much code / configuration of protobufs / processing to manage. Changes:
Unresolved questions -- feedback welcome:
|
…/responses Signed-off-by: Stephen Curran <[email protected]>
Signed-off-by: Stephen Curran <[email protected]>
|
WG 20240124 implementation under way in ACA-Py. |
Signed-off-by: Stephen Curran <[email protected]>
The DIDComm Remote Procedure Call (DRPC) protocol enables a JSON-RPC-based request-response interaction to be carried out across a DIDComm channel. The protocol is designed to enable custom interactions between connected agents, and to allow for the rapid prototyping of experimental DIDComm protocols. An agent sends a DIDComm message to request a remote service be invoked by another agent, and gets back a response in subsequent DIDComm message. The protocol enables any request to be conveyed that the other agent understands. Out of scope of this protocol is how the requesting agent discovers the services available from the responding agent, and how the two agents know the semantics of the JSON-RPC requests and responses. By using DIDComm between the requesting and responding
agents, the security and privacy benefits of DIDComm are accomplished, and the generic parameters of the messages allow for flexibility in how and where the protocol can be used.
The initial proposed use of this protocol is for App Attestation.