search

decentralized-identity / interoperability

The archive and information hub for the cross-community interoperability project. Focus is on education and familiarity for various efforts across multiple groups for interoperable decentralized identity infrastructure.
https://identity.foundation/interop/
Apache License 2.0
92 stars 19 forks source link

Add support for CHAPI #24

Closed OR13 closed 3 years ago

OR13 commented 4 years ago

A possible option for getting credentials to a wallet:

https://github.com/digitalbazaar/credential-handler-polyfill

If we could demonstrate how this works with at least 1 mobile wallet, it might help encourage wallet implementers to support this standard.

vongohren commented 4 years ago

This is cool. One questions though, where is the digitalwallet held? I did not completly understand that

OR13 commented 4 years ago

Its a web wallet in these cases, so it exists in a service worker... you would need to write an adapter for cloud wallet / mobile app backends, and connect them to the service worker.

msporny commented 4 years ago

Its a web wallet in these cases, so it exists in a service worker... you would need to write an adapter for cloud wallet / mobile app backends, and connect them to the service worker.

Note that it's theoretically possible to bridge CHAPI to native apps. We have a couple of on-paper designs to do that, but are blocked by not having a native wallet implementer that's interested in working with us to build out the solution to their native wallet. Native wallet support is on the roadmap for CHAPI, but without a development partner, we're not going to be able to make much progress.

CHAPI works just fine for Web-to-Web interactions (Web-based issuer to Web-based wallet).

I think @dmitrizagidulin has a tutorial that might be helpful.

dlongley commented 4 years ago

Note that native wallets could be potentially supported by updating the polyfill server to run a WebRTC/ICE server to enable the use of WebRTC for communicating responses to the user's browser. We would need to see a native app provider show interest in participating in this work for it to happen.

vongohren commented 4 years ago

Ok, so when you guys are saying "native wallet apps". Im still a bit stuck in the ethereum world of how a wallet app is percieved and how uPort has currently done their wallet app.

We have a "native app" that works as a service on top of your identity, that currently provides you with a profile, a way to see your issued credentials and attended courses, and from there you can claim them to your identity, which now is uPort. Because that is where the user holds his keys and can approve signatures and hold the data in their control.

We have a web interface for issuers to do issuance and signing, but it is via our backend now, but the issuance and signing happens with the users uPort wallet.

I think I just might be lagging a bit behind on the architectural possibilities of this. So I would love if any of you would have time for a short meeting on discussin what this entitles and how our architecture fits into this.

We are in the process of needing to improve the uPort process, because it is a hinder for our users. So Im looking at possibilties of being able to do this

msporny commented 4 years ago

@vongohren this is an old video, but might give you some ideas on the architecture: https://www.youtube.com/watch?v=bm3XBPB4cFY

OR13 commented 4 years ago

^ this is pretty much what DIF has been wanting to build for a really long time... The main reason we don't have such a demo is that we can't figure out how to integrate with mobile apps....

dlongley commented 4 years ago

The main reason we don't have such a demo is that we can't figure out how to integrate with mobile apps....

So we have a rough plan for integrating mobile apps in with CHAPI, we just need a mobile wallet app developer that is interested in helping out with the implementation.

In short, selecting a native app could be added as a choice in the CHAPI UI. If the user made that selection, the CHAPI request would be downloaded using a mime type that a mobile app could understand -- such that the user could select the mobile wallet app to use (including setting a default for next time). The CHAPI request would also include some WebRTC pairing information/endpoint that the mobile wallet app would use to send the CHAPI response once it was processed (including any potential user interaction). The mobile app would then send the user back to the browser which would have received the CHAPI response just like it would have from a Web app -- and the user would carry on like usual.

dlongley commented 4 years ago

Note that you can run through the current demo on your own here:

https://credential-repository.demo.digitalbazaar.com/

msporny commented 4 years ago

Note that you can run through the current demo on your own here

If you are using Chrome, do this in an incognito tab... you don't want the demo wallet installed in your standard browsing context, and doing it in an incognito mode helps you do the demo from end to end and see all permissions dialogs.

vongohren commented 4 years ago

This is great stuff, this works on a mobile browser, so basically on a PWA right? I did test it in the browser and the same stuff popped up.

dlongley commented 4 years ago

Yes, works in a mobile browser and with regular Web apps and PWAs.