RFC 0829: VDR Proxy

[swcurran]

A VDR (verifiable data registry) is a place where DIDs and objects related to
DIDs (such as Hyperledger AnonCreds objects) are stored such that they can be
resolved. The VDR Proxy protocol defined by this RFC is a DIDComm protocol that
can be used by a DIDComm agent to request another agent resolve VDR URIs
(Uniform Resource Identifiers) and return the resolved objects to the
requesting agent. The protocol is a simple client/server protocol, supporting
the ability to request and receive back multiple resolutions in a single exchange.

[TimoGlastra]

Wouldn't the DRPC protocol be well-suited to handle this?

Especially since the request/response types are not modeled, this feels like it will be quite hard to use in a general purpose way. Should there be some type registry for format response structures that can be extended with custom types by implementers if they like?

It's not clear to me whether a request for did:indy:123 should return the JSON Did document, the DID Document with metadata (as can be returned in a did resolver), or rather the response itself from the ledger (given it's a proxy I would assume the latter, is that correct?)

Also -- given it's a proxy, shouldn't you also provide the raw (signed?) ledger request that will be submitted to the ledger? A lot of ledgers expose RPC servers where you submit your transactions. This could work similarly, or is it only really meant to focus on reading from a VDR?

I feel it may be beneficial to make things a bit more explicit and focused on a specific use case, but maybe I don't understand the goal of the RFC well-enough yet

[swcurran]

Regards using DRPC. I did think about it, and borrowed heavily from that RFC in doing this.

Wouldn't the DRPC protocol be well-suited to handle this?

The main reason for not using DRPC is that in this case, the Aries agent acting as the proxy will handle the DID resolution within the framework, vs. the controller handling the requests as is expected with DRPC. Not to say it couldn't be done using DRPC, or by a controller, but that since a framework generally supports DID resolution already, it should handle this.

It's not clear to me whether a request for did:indy:123 should return the JSON Did document, the DID Document with metadata (as can be returned in a did resolver), or rather the response itself from the ledger (given it's a proxy I would assume the latter, is that correct?)

Good point and we need to clarify that. I had expected that the JSON DID Document would be returned (or the Schema, CredDef, RevRegDef, and RevRegEntry). As I type that, I realize that might break down with the last item, because of how (specifically) Indy handles RevRegEntry requests. Feedback on what should be returned from a RevRegEntry read would be most welcome!! This is complicated by the historical close association of Aries/Indy that may not yet be fully abstracted away in the implemented code. Ideally, Indy DIDs and AnonCreds objects are resolved in all Aries implementations identically to any other VDR. If we aren't there yet, Perhaps this implementation could help move to that.

The JSON document vs. JSON document + metadata is an interesting point. I'm not as involved at that deep a level and would welcome input from others.

Also -- given it's a proxy, shouldn't you also provide the raw (signed?) ledger request that will be submitted to the ledger? A lot of ledgers expose RPC servers where you submit your transactions. This could work similarly, or is it only really meant to focus on reading from a VDR?

The intention is on reading, and most importantly the "mobile agent blocked by the firewall" example. I'm not aware of a need for proxied writes to a VDR.

Thanks for the feedback. I'll try to rework the details around resolution.

[cvarjao]

we could model as a DRPC protocol handled by the mediator, code it, and when it is ready/working, we propose it as a top-level protocol. I was initially thinking as just a raw proxy to ledgers, no extra metadata (initially). The main problem (use case) is for accessing ledgers when non-http ports are blocked by organization firewall.

[JamesKEbert]

Very exciting to see this proposal, it's quite cool to see progress here!

Especially since the request/response types are not modeled, this feels like it will be quite hard to use in a general purpose way. Should there be some type registry for format response structures that can be extended with custom types by implementers if they like?

Agreed--having an explicit format of request/response messages seems critical to the success of implementing the protocol.

I feel it may be beneficial to make things a bit more explicit and focused on a specific use case

Although we're trying to make things generally more open-ended, gearing this RFC towards Indy might be wise? Let the first version be geared towards a specific use case and future versions be more general purpose and learning from the mistakes or issues found in the first version.

[JamesKEbert]

Needs a reference/link to either Problem Report or the appropriate section of the RFC

[JamesKEbert]

Suggested change

	- `@id` -- required, must be as defined in [RFC 0005 DIDComm]
	- `@id` -- required, must be as defined in [RFC 0005 DIDComm](../concepts/0005-didcomm/README.md)

[JamesKEbert]

Suggested change

	- `@id` -- required, must be as defined in [RFC 0005 DIDComm]
	- `@id` -- required, must be as defined in [RFC 0005 DIDComm](../concepts/0005-didcomm/README.md)

[JamesKEbert]

Suggested change

	[RFC 0804 DIDComm RPC]: ../0804-didcomm-rpc/README.md
	[RFC 0809 DIDComm Remote Producer Call]: ../0804-didcomm-rpc/README.md

[JamesKEbert]

Another consideration regarding caching--if caching is something we want to implement in this first go-around, we may want to provide an optional way for the Client to indicate their tolerance for caching. For instance for a regular request a Client might not care if it's a day or two old, but for something like revocation data it may be crucial to have that be freshly retrieved.

[TelegramSam]

Discussion WG 20240529

• how does this fit in bifold? (asking team)
• are we requesting transactions? Objects?

[thiagoromanos]

My team develop a proxy to work with bifold because there is an ISP here in Brazil that blocks ZMQ protocol when you're on iOS using mobile data (yes, specific like that). Our solution here was to develop a REST service that reads from the ledger using a credo-ts agent, and bifold reaches to this service instead of the ledger directly. In our case here, we requested only the objects.
I believe that this proxy protocol will follow a similar idea, but in a way more elaborate way.

[thiagoromanos]

One thing that it's not clear yet to me is about the response timing. Say that a alice agent receives an credential offer from a faber agent and wants to accept this offer. alice will request the proxy agent the credential definition which is in the ledger, but there is no way to know if or when the response will come. In IndyVDR those requests acts like a http request, that the response comes right after the request (or an error code comes if the service is unavailable, some error occurred, etc.). How will we handle this when we use the proxy to get, for example, the credential definition without knowing if or when the response will come?

[TelegramSam]

Discussed WG 20240911
Sam to provide link to strategies for awaiting a DIDComm response.

[TelegramSam]

Discussed 20241016. Sam's explanations of message handling flows will happen at IIW, but won't modify protocols such as this one. No objections to merge.

[TelegramSam]

see discussion note