Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support receiving out of band invitations with public dids for the didexchange protocol #992

Closed
TimoGlastra opened this issue Aug 26, 2022 · 6 comments
Assignees

Comments

@TimoGlastra
Copy link
Contributor

#930 adds support for receiving out of band invitations with public dids, but only supports processing it for 0160 connections. We should still add support to do this with the didexchange protocol

@genaris
Copy link
Contributor

genaris commented Oct 19, 2022

Maybe related to this: how about the "implicit invitations" in DID Exchange protocol? From the RFC my understanding is that the protocol can be started either by an OOB invitation or the resolution of a Public DID.

Currently, DidExchangeProtocol.createRequest requires an outOfBandRecord among its options, which makes me think that it's only intended for the explicit invitations. That means this is not supported, or should it be supported by previously creating a 'local' OutOfBandInvitation containing public DID as service field and calling oob.receiveInvitation? (however I don't think the responder would accept it given that pthid will point to an unknown thread).

For context: the flow I'm trying to solve is the one where I receive a proof request specifying a credential definition id and, as I don't have a matching credential, I want to connect with the issuer (in Indy I can get its public DID just by inspecting the credential definition id) to ask for the issuance. Should I solve it with an connection-less flow? In such case, will I be able to create this 'implicit OOB invitation' containing the public DID?

@TimoGlastra
Copy link
Contributor Author

That's an interesting way to get the credential you need!

I think yes, currently the flow doesn't take into account the implicit flow. What would be the easiest approach I think is to keep the DidExchangeProtocol.createRequest to need a out of band record, that we can create on the module layer beforehand. Another approach would be to create a DidExchangeProtocol.createRequestFromDid and ConnectionService.createRequestFromDid and expose it through a ConnectionsApi.sendRequestToDid or something similar (don't like sendRequestToDid too much).

I think it would work fine with the pthid:

When a request responds to an implicit invitation, its ~thread.pthid MUST contain a DID URL that resolves to the specific service on a DID document that contains the invitation.

We should modify the request to include the public did with service as the pthid, like so: https://github.com/hyperledger/aries-rfcs/blob/main/features/0023-did-exchange/README.md#example-referencing-an-implicit-invitation

The connectionless flow should also work I assume and is probably easier to implement, so I think it's a bit dependant on which flow works best for your use case. At the moment we don't support proposals for connectionless credential issuance though

@genaris
Copy link
Contributor

genaris commented Oct 19, 2022

Thanks for the explanation and suggestions @TimoGlastra ! I think it would be nice to support these implicit invitations from the module level in order to make it more evident for users how to handle both invitation types. I'll dig a bit more about the possibilities and open a PR including these public DID handling in DIDExchange protocol.

@TimoGlastra
Copy link
Contributor Author

@genaris are you still working on this?

@genaris
Copy link
Contributor

genaris commented Nov 10, 2022

Slowly but yes!

@genaris
Copy link
Contributor

genaris commented Nov 22, 2024

I think #1348, combined with the support of resolvable DIDs in DID Exchange in #1550 covered this, unless I'm missing something.

@genaris genaris closed this as completed Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants