-
Notifications
You must be signed in to change notification settings - Fork 11
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
Holder initiated Presentations #118
Comments
update .... we're working on this now with a grant! |
@mixmix , so should this issue be assigned to you? |
@mkbreuningIOHK what does "assigned" mean in your org context? cc @elribonazo here is an example of me asking for more power at the "edge" (shift towards fully p2p agents) |
Getting back to this to make some real progress. On our most recent improvements we've included SDK to SDK verification through DIDS and didcomm. Also have integrated ConnectionLess flows. Let's re-open this thread and try to make some progress. We still need to make Connectionless flows re-usable thats last thing i can think of right @mixmix ? |
Yes! @chereseeriepa and I have been working on getting the new SDK woven into Ahau. We have integrations tests passing, and it's beautiful! Next up from us:
|
Proposed feature
For our use-case in Ahau, we want presentations to be part of our Tribe Registration process.
We have secure end-points (public keys you can encrypt messages to) where it is safe to send messages to Kaitiaki (custodians/ guardians/ admins of a Tribe).
Here:
At the moment we have an slightly annoying workflow which goes:
Each of those steps could have significant delays. The applicant may be applying from their phone/ laptop, and the kaitiaki is maybe reviewing applications from their laptop. They are not assumed to be both online at the same time, so each asynchronous step could make significant hold-up for a process
Feature description
The steps we would prefer:
Anything else?
NOTE: we use scuttlebutt messages to communicate state-progression (which initiates actions) between the applicant (a Holder using the SDK) and the kaitiaki (Verifier, using a hosted Agent via https APIs)
The text was updated successfully, but these errors were encountered: