Adopt list of supported Identity Wallets

[OR13]

Please add Identity Wallet Mobile apps that would like to be supported, and comment on the idea of implementing a QR Code flow.

[OR13]

Transmute ID is a PWA, but we have the ability to scan QR Codes, I think we can support the DID Auth Flow. Our codebase is JavaScript. Our approach would likely not be reusable by mobile wallets because of the client-server architecture.

[ipatka]

BloomID is an identity wallet with the ability to scan QR codes and route deep links for credential sharing and authentication. Server side is Typescript. Clients are in Swift and Java using a shared c++ crypto library for signing. If anything is useful for other wallets we would be open to packaging it into an open source repo.

[kdenhartog]

I'll make an announcement on the Aries call tomorrow to mention companies who want to join should come in here and comment.

[brentzundel]

Evernym has a mobile agent with an identity wallet that uses QR codes, but I'm not sure what it would take for it to be a "supported identity wallet." What would this actually entail?

[vongohren]

Uport is using React Native, and scans QR code. Our app is far from ready but my efforts so far is going in that direction

[OR13]

Excellent, thanks kicking off the conversation.

For an Identity Wallet to be supported, it must implement protocol / data structures necessary to complete the interop demo (a simple credential issuance and presentation flow).

While some of these concepts are still being ironed out, we do have some higher confidence assertions:

1. The Auth Flow will use OIDC SIOP, a client will need to sign and verify ES256K JWT, that are encoded in QR Codes.

2. The client will likely need to render a W3C VC format as described here: https://github.com/decentralized-identity/interop-project#credential-format

I think we should focus on OIDC SIOP to start.

That means that the clients will need to be able to sign and verify ES256K JWT, and scan QR Codes.

It sounds like there are a couple different languages which would need to be supported.

I suggest we build a javascript SDK for demoing this first, and then we can figure out how to get interoperability tests for Java, C++, etc...

[awoie]

@OR13 yes, I'm setting up the respective repositories in GitHub in the course of the Authentication WG.

[Joachim16]

Jolocom SmartWallet is in React Native with ability to scan QR codes. there is deep linking for credential sharing and authentication. backend is Typescript.

[OR13]

Seems like QR Codes are well supported, but the question is what data is presented in the QR Code.

I think we will likely find that existing apps have varying expectations here.

If the QR Code is exactly a JWT, I think thats the easiest for interoperability.

[cboscolo]

@OR13 if the QR codes is "exactly a JWT", would that mean that someone scanning it using the iPhone camera (not via an app) would not have a good user experience since it wouldn't know what app to launch?

[OR13]

yes, good point, from discussions elsewhere. We seem to be heading for a URI format like:

openid://<jwt>

app://<jwt>

app://expand?request=<jwt>

We probably need some kind of spec hosted in the DIF that organizes these approaches.

[awoie]

@cboscolo

if the QR codes is "exactly a JWT", would that mean that someone scanning it using the iPhone camera (not via an app) would not have a good user experience since it wouldn't know what app to launch?

Yes! But we could register the URL scheme with IANA, then there is a chance that the behaviour changes on iOS. We are trying to do this for openid://.

Another approach is to use custom MIME-types but the UX would still be very unusual.

[awoie]

yes, good point, from discussions elsewhere. We seem to be heading for a URI format like:

openid://<jwt>

openid should not be used for credential issuance, only for openid requests.

We probably need some kind of spec hosted in the DIF that organizes these approaches.

Yes, and if we decide on a custom URL scheme, then we should also register it with IANA.

[hob]

Having the QR code exactly be a JWT simplifies the flow, but it might lower the bar a bit if the QR were just a URL. If it were assumed that flow started with fetching the JWT from a URL 1st, then the QR becomes optional and the barrier to entry would be lower. It would enable features like direct linking for mobile devices where a QR presents a bit of a chicken/egg problem (the phone can't scan its own screen).

[alenhorvat]

Hi. We (Netis/AceBlock) have a working SSI Mobile app, a web-snippet (QR code part) and a backend agent for verifying the OIDC-SSI token for a year. Our QR Code content is a JWT. We also implemented the mobile-browser-mobile-SSI app (deep link) functionality. The mobile part is in Java, web part in JS, server-side part in JS. A year ago the OIDC implementations did not support the ES256K JWT signatures, nor OIDC-SSI tokens.
We also have a server-side fix for .NET and LUA. (it should be rewritten)

Core parts of the libraries will be open source. If you need any help/input, let me know.

(the phone can't scan its own screen) -- we have solved this using deep-links. For interoperability, all SSI apps should follow the same URI format.

[OR13]

@alenhorvat please add links to any implementations if possible, especially your existing URI format, thanks for adding your voice.

[alenhorvat]

Here is the demo page: https://id.aceblock.com/ (Mobile app is not public, yet. V1 is for the demo, V2 is expected to be available by end of the year.)
Web-site JS module: https://www.npmjs.com/package/@aceblock/aceblock-login-qr
Auth. flow is the same as OIDC-SSI (and also DID-AuthN SIOP).

I will provide more info about the URI in the following days.

[ipatka]

We just released a CLI which replicates much of the functionality for the Bloom app for prototyping and testing purposes. https://github.com/hellobloom/bloom-credential-playground

It is not yet compliant with the interop mechanisms for did creation, credential issuance, etc but my plan is to prototype the interop features in the CLI then migrate it into the mobile app when ready.

[alenhorvat]

URI Format: at the moment we're using: app_name:base64_encode(oidc_request) <- this should be standardized (e.g., ssi:oidc_auth: for an OIDC-SSI compliant authentication). The oidc_request complies with the OIDC-SSI and DID-Auth SIOP (for authentication only). VC/Attestation request flows are not defined at the moment. Question: are deep-links and QR codes secure way of transferring information from a client to an SSI Agent?

[kdenhartog]

I would not consider a QR code a secure method of transferring information. They should be considered an insecure method of transmitting data.

[OR13]

If the QR Code is a JWE... its as secure as JWE...

Size limits of QR Codes means usually they will be either a resource that can be protected with whatever authorization scheme or a JWE... I'd love to to see OIDC SIOP actually tested in the wild, before we got any further down the QR Code rabbit whole for AuthZ / credential exchange.

[brentzundel]

OIDC SIOP in the wild: https://www.linkedin.com/posts/truu-id_passwordless-digitalpassport-seeyouinthefuture-activity-6589215033199259648-NRel

[kdenhartog]

If the QR Code is a JWE... its as secure as JWE...

Size limits of QR Codes means usually they will be either a resource that can be protected with whatever authorization scheme or a JWE... I'd love to to see OIDC SIOP actually tested in the wild, before we got any further down the QR Code rabbit whole for AuthZ / credential exchange.

Yes, this is a better way of saying what I was trying to.