Connections / DID Exchange / DID Document URI-less endpoints

[TelegramSam]

trafficstars

The Connections and DID Exchange Protocol involves the exchange of DIDs and DID Documents. I'm curious how we should handle one particular case. When an edge agent without a mediator (ex: mobile app) connects to a cloud agent, the edge agent has no URI to give to the cloud agent. The implication is that the edge agent will 'call in' and retrieve messages held by the cloud agent, rather than having the cloud agent send the messages to a provided URI. The tricky thing is that the DID Document still needs something like a service block to help the other party know which keys are used for encryption. The only thing missing is the URI. I figure we have roughly three options:

1. Have a service block with no URI.
2. Have a service block with an empty string for a URI
3. Have a service block with an agreed-upon URI that means the right thing.

Commentary on options:

1. This might make us run afoul of the DID Spec, and feels broken instead of intentional.
2. This is what ACApy currently does. aries-framework-dotnet doesn't allow this.
3. This might be the clearest answer, depending on what URI is used.

Thoughts? Comments?

Limitation: Two agents without endpoints cannot connect. What does this mean for agents that connect over bluetooth? Can the same solution apply there?

Additional note: A common use case would be a mobile agent connecting to a mediator. After connecting, the mobile agent coordinates with the mediator to route for it. With future connections, the mobile agent uses the endpoint and routing keys provided by the mediator.

[TelegramSam]

@dhh1128 @tmarkovski @swcurran

[dhh1128]

I think I like option 2 the best; it's explicitly and accurately claiming that there is no endpoint. If aries-framework-dotnet doesn't like the empty string, we could do option 3 by defining a URI value of "didcomm://tbd" or "tbd" that just means, "The specifics of which endpoint to use are still 'To Be Determined' later, per circumstances."

[swcurran]

I agree that option 2 is best--very clear. Option 3 is OK, but awkward, particular when we are talking about something to be used globally. What exactly does "TBD" (or any other term we pick) mean in Malaysia?

[TelegramSam]

I committed a markdown fumble in the original post. I've edited to represent what I had originally intended.

[TelegramSam]

After some reading (https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) and thinking, I think option 3 with this uri is what I'm recommending: didcomm:transport/hold This is a valid URI (which does not require an //authority) and is a googleable string.

I worry that an empty string looks far too similar to an error or oversight. Using an explicit value avoids that confusion.

[dhh1128]

I had not considered the desirability of having something that's google-able and that helps developers who don't know what they're looking at. I'm not opposed to @TelegramSam 's suggestion...

[rolsonquadras]

After some reading (https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) and thinking, I think option 3 with this uri is what I'm recommending: didcomm:transport/hold This is a valid URI (which does not require an //authority) and is a googleable string.

I worry that an empty string looks far too similar to an error or oversight. Using an explicit value avoids that confusion.

In aries-framework-go, currently we are using "routing:endpoint" as the endpoint for the case described in this issue. This proposal here would just require a constant to be updated in the codebase.

[dhh1128]

@TelegramSam : could you comment on the significance of the "transport" part of the URI you propose? Are you assuming that what is on hold is a choice of transport?

[TelegramSam]

@dhh1128 yeah, mostly. It was the least confusing thing I could come up with. Totally open to better ideas.

[TelegramSam]

didcomm:transport/pickup didcomm:transport/none

[TelegramSam]

didcomm:transport/queue

[TelegramSam]

@dhh1128 I'm realizing that this relates more to Peer DIDs than it does to any specific protocol within Aries. Does this concept have a home in that conversation?

[kdenhartog]

fitting this into the transport layer seems a bit off to me, but I don't have an alternative proposal yet. Still thinking of a good way to represent this.

For me, this feels like a pattern of usage of transports rather than a transport itself which is why I'm not certain. It's kinda like how mediators are a pattern for a particular role in routing. Similarly this feels like a pattern for how 2 different roles may interact, which is where my hesitancy around putting it at the transport layer seems off. I'm hoping I may find a better place to put this without having to create another property field for the service block.

[llorllale]

I would have thought RFC0092 would fulfill this use case:

    "~transport": {
        "return_route": "all"
    }