Hello, is it possible to integrate a traditional mobile app with a credential issuance canister? How can it be done? I would like to use this information to advice a financial institution that is trying to use ICP for this.
2 Likes
Hi!
It is possible for a mobile app to integrate with issuer in the IC, but not directly.
The app should use a webpage as a proxy to get the credential and then redirect to the mobile app.
The webpage could or could not be hosted in IC. If it’s not hosted the support is not yet as good as would like to, but still doable. We have a demo using web2 project in a branch in the Internet Identity repository.
If it’s a webpage hosted in a canister in IC, then it can use the Verifiable Credentials SDK.
Let me know if this is helpful or you have any more questions.
Which one of the following scenarios does your description apply to?
- A mobile app issuing a verifiable credential to a user logged in with ii on a traditional mobile app
- A relying party connecting to an issuer canister to verify a verifiable credential that a user claimed to have (like is done by oc.app to check if a user has a mentioned credential)
I am interested in the first scenario for issuing a verifiable credential to a user logged in with ii on a traditional mobile app.
I meant number 2.
For scenario number 1, only a canister can issue credentials at the moment.
Could you describe better your use case? The feature has just started and we’d like to collect as many use cases as possible to prioritize what the work on next?
Thanks!
Hey, maybe you can also prioritize VC for Motoko canister as well. We have a potential use case for online course certificates.
1 Like
Thanks for sharing!
Supporting Motoko is on our roadmap as well.
We haven’t finished our SDK yet. But our priorities have changed in the short term. As soon as we pick up work on the SDK we’ll add the Motoko part.
I’m assuming you are interested in the SDK to become an issuer of credentials in Motoko, right?
yes that’s true. We use VC already according the W3C standard, but in a traditional way and it would be great if we can reimplement VC with II on our platform.
The customers use the financial institution’s mobile app (Android and iOS app connecting to a core banking system in the data center), to access banking services.
The financial institution would like to present the customers a screen on the mobile app where they can login using ii, then a screen where the customer can see a number of possible credentials to claim onto the ii (such as “I am a customer of bank x”, “I am a platinum customer of bank x”, “My date of birth is x”). The customer can then claim the credentials that they qualify for, hence why the financial institution needs this ability to issue verifiable credentials to users of the mobile app.
Then when the customer logs in using their ii at a relying party (such as on oc.app or a CRM supporting ii), the verifiable credentials that they hold on their ii can be recognized and the customer can be treated preferentially. E.g. if on oc.app, customer can be admitted to exclusive channels gated by the verifiable credentials issued by the financial institution, and to be engaged and rewarded (such as airdropped red envelopes, announcements, etc).
1 Like
At the moment, the only way to accomplish this is to move these credentials from the mobile app to a canister.
We were also thinking on supporting some common standards so that canisters could use credentials from web2, I believe this would be your case. However, this is still a bit long in our roadmap.
Thanks for sharing the use case!
Do you mean you implement the verifiable credential W3C data model standard? May I ask how relying parties connect to your issuer at the moment? Do you use Open ID for VC?
Thanks!
Could you elaborate further on “move these credentials from the mobile app to a canister”, in a way that the above use case can be achieved, and possibly provide a link to any demo that does this?
To issue credentials in Internet Computer, one needs to develop a canister that exposes a certain set of endpoints and performs a certain set of tasks.
From the mobile app, those credentials could be sent to the canister, who could then expose them through those endpoints. You can find more info about calling ICP from a client here.
We have also provided the community with two demos that implement an issuer:
- Attendance Issuer.
- VC Playground. Which also includes a relying party.
I leave the documentation on how to become an issuer here.
I hope this is releavant and helpful for your project.
3 Likes
Thanks for the information. I will review.
Right now, II’s VC protocol is interactive and wallet-less, i.e., presenting a credential means going through II to the issuer each and every time a credential is required (ofc we will optimise that in the future with caching, just stating how things stand right now). So it’s not a traditional VC protocol that can operate offline and uses an identity wallet to present a credential from the wallet to the verifier - II’s VC protocol currently requires issuers to be on smart contracts and be available to respond to credential requests.
So, it’s possible to implement a credential-issuing process which requires a mobile app, but the mobile app will have to ultimately store credentials in a canister. There are some other considerations here as @lmuntaner wrote, but it’s possible to make it work I believe.
Very interesting use case though, let us know if you have further questions.
1 Like
I anticipate the best way to do this will be to use the upcoming Digital Credentials API that the Chrome and Safari teams have been collaborating on.
I’ve seen it demoed at a conference, but it will allow browsers to request WC3 Verifiable Credentials from native mobile apps securely, both from the same device and across devices
2 Likes
The other aspect of VCs that might be needed is ability promptly expire credentials that are no longer valid. For example, today the user might be a customer of the bank X, and tomorrow not. So the customer should not enjoy preferential treatment anymore based on a VC that no longer represents their true current status.
Definitely, currently II’s VC protocol is mostly an exchange protocol, we use signed JWT internally, but the VC representation is left to be decided between issuers and RPs. This is in turn means that things like expiration semantics are left to the dapps.
1 Like
I would guess expiration of credentials is difficult. Part of the value proposition of a verifiable credential is that it can be independently verified, that is, the consumer of a VC can check its authenticity without communicating with the issuer. If the consumer would have to check with the issuer if credential is still valid then the whole concept of VCs is less appealing.
This is the challenge that I see as well, and that requires a solution.
In this case where the credentials are in a canister, can the issuer come back later to expire them without the involvement of the subject/holder? For example, if the subject is no longer a customer of financial institution x, can the institution later go and expire the credential in the canister?