-
Notifications
You must be signed in to change notification settings - Fork 10
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
PROPOSAL: Define support for DIDComm / WACI-PEx #17
Comments
we should put this into a implementation guide @OR13 |
There is progress being made, but v0.1 release has still not shipped. |
discussed on call and will revist one v0.1 is in place |
Status update: w3c-ccg/universal-wallet-interop-spec#99 |
@OR13 can you maybe walk us through this proposal on a call |
@OR13, we need to have you on the call for this. |
I'm not in favor of adding DIDComm at this time. I'm not in favor of adding WACI / Presentation Exchange at this time. I am happy to leave this issue open or close it. |
See also w3c-ccg/vc-api#245 |
There are valid requirements for having vc pushed to your wallet. But this may belong better on vc-api. |
I see issues similar to FTP(control,data) distinct connections, where special switches must be flipped in order to have the client initiate both connections, rather than having client initiate control and server initiate data. This will need strong consideration in the VC API world, along push+pull vs pure_push vs pure_pull vs pull+push |
Keeping this ticket around for keeping us updated |
We discussed implementation timeline for WACI / PEx / DIDComm. There is no timeline for their implementation here. These related PRs might impact our decisions in the future: |
as discsused, we are all awaiting didcomm v2 imps |
didcomm v2 implementations still not available. |
didcomm v2 implementations still not available. |
openwallet-foundation/owl-agent-test-harness#444 Seems to be available now. |
We won't close this until the issue above is addressed. |
We still have not addressed the issue. |
If no one is planning to implement didcomm, we should stop spending time discussion this issue. |
Closed |
WACI-PEx describes an alternate flow for exchanging verifiable presentations:
https://github.com/decentralized-identity/waci-presentation-exchange
Unlike the vc-http-api, it is built on top of message level encryption for DIDs, according to a spec called https://github.com/decentralized-identity/didcomm-messaging
The advantage of WACI-PEx is that messages can flow other transports other than HTTP.
The spec also makes use of https://github.com/decentralized-identity/presentation-exchange
Which defines extensions for verifiable presentations that a verifier can use to request specific kinds of presentations from holders.
I would like to define support for this once it stabilizes so we can establish interoperability with other DIF companies and TOIPs Good Health Pass.
I think for sanity sake, we would need new endpoints for this, luckily they would be generate "DIDComm" service endpoints.
The text was updated successfully, but these errors were encountered: