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.

[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]

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.