Deep linking

[ejossev]

Hi,

I'm playing with the wallet, and for our use case, we would need to pass to the wallet issuance/presentation URLs from other application. Looking at the code, it seems that the URL is passed to the qr handler, which, in case of URL, looks at the oob param and handles it as base64-encoded JSON object (https://github.com/Sphereon-Opensource/ssi-mobile-wallet/blob/develop/src/services/qrService.ts#L95-L101). So I tried e.g. this kind of deep links:

com.sphereon.ssi.wallet://?oob=ewogInVyaSI6ICJvcGVuaWQtdmM6Ly8/cmVxdWVzdF91cmk9aHR0cHMlM0ElMkYlMkZ2Y3ZhbGlkYXRvci12Y3ZhbGlkYXRvci5henVyZW1pY3Jvc2VydmljZXMuaW8lMkZhcGklMkZzcGhlcmVvbl9hdXRoJTJGZ2V0VG9rZW4lMkYxODYwIiwKICJ0eXBlIjogIm9wZW5pZC12YyIKfQ==

But all what happens is, that the wallet opens, asks for pin and then nothing - just shows the main screen, not even an error message. What am I doing wrong?

Thanks/josef

[ejossev]

I can add that I see in the backend logs that the wallet downloaded the request object:

eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDpqd2s6ZXlKcmRIa2lPaUpQUzFBaUxDSmpjbllpT2lKRlpESTFOVEU1SWl3aWVDSTZJa3BaUTBGSGJEWkROMmRqUkdWTFlrNXhkRmhDWm5CSGVrZ3daalZsYkdsbWFqZE1ObnBaVG1wZlNYTWlmUSMwIiwidHlwIjoiSldUIn0.eyJpYXQiOjE2OTU5MDM0MDEsImV4cCI6MTY5NTkwMzYxNywicmVzcG9uc2VfdHlwZSI6ImlkX3Rva2VuIiwic2NvcGUiOiJvcGVuaWQiLCJyZXNwb25zZV9tb2RlIjoicG9zdCIsImNsaWVudF9pZCI6Imh0dHBzOi8vdmN2YWxpZGF0b3ItdmN2YWxpZGF0b3IuYXp1cmVtaWNyb3NlcnZpY2VzLmlvIiwiaXNzIjoiZGlkOmp3azpleUpyZEhraU9pSlBTMUFpTENKamNuWWlPaUpGWkRJMU5URTVJaXdpZUNJNklrcFpRMEZIYkRaRE4yZGpSR1ZMWWs1eGRGaENabkJIZWtnd1pqVmxiR2xtYWpkTU5ucFpUbXBmU1hNaWZRIiwic3ViIjoiZGlkOmp3azpleUpyZEhraU9pSlBTMUFpTENKamNuWWlPaUpGWkRJMU5URTVJaXdpZUNJNklrcFpRMEZIYkRaRE4yZGpSR1ZMWWs1eGRGaENabkJIZWtnd1pqVmxiR2xtYWpkTU5ucFpUbXBmU1hNaWZRIiwicmVkaXJlY3RfdXJpIjoiaHR0cHM6Ly92Y3ZhbGlkYXRvci12Y3ZhbGlkYXRvci5henVyZW1pY3Jvc2VydmljZXMuaW8vYXBpL3NwaGVyZW9uX2F1dGgvc3VibWl0Iiwibm9uY2UiOiJvZW4xQWNZZUo5YzBCSW1GSm1sZFBRZGdiRkprRTF1SSIsInN0YXRlIjoidE53M21ZUWVqV0daZnNyNzR1NHVPQmFsOWZ5R1J0TjAiLCJqdGkiOiJUVlJuTkU1MyIsImNsYWltcyI6eyJ2cF90b2tlbiI6eyJwcmVzZW50YXRpb25fZGVmaW5pdGlvbiI6eyJpZCI6InVuaXF1ZW5lc3MgY3JlZGVudGlhbCIsInB1cnBvc2UiOiJDb25maXJtIHdpdGggeW91ciB1bmlxdWUgaWRlbnRpZmllciIsInN1Ym1pc3Npb25fcmVxdWlyZW1lbnRzIjpbeyJuYW1lIjoiVW5pcXVlbmVzcyBwcm9vIiwicnVsZSI6InBpY2siLCJtaW4iOjAsIm1heCI6MSwiZnJvbSI6IkEifV0sImlucHV0X2Rlc2NyaXB0b3JzIjpbeyJpZCI6InVuaXF1ZW5lc3MgY3JlZGVudGlhbCIsInB1cnBvc2UiOiJDb25maXJtIHdpdGggeW91ciB1bmlxdWUgaWRlbnRpZmllciIsIm5hbWUiOiJVbmlxdWVuZXNzIHByb29mIiwiZ3JvdXAiOlsiQSJdLCJzY2hlbWEiOlt7InVyaSI6Imh0dHBzOi8vdmN2YWxpZGF0b3ItdmN2YWxpZGF0b3IuYXp1cmVtaWNyb3NlcnZpY2VzLmlvL2NvbnRleHRzL3VuaXF1ZW5lc3MvdjEuanNvbmxkIn1dfV19fX0sInJlZ2lzdHJhdGlvbiI6eyJpZF90b2tlbl9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkIjpbIkVkRFNBIiwiRVMyNTYiLCJFUzI1NksiXSwicmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZCI6WyJFZERTQSIsIkVTMjU2IiwiRVMyNTZLIl0sInJlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCI6WyJpZF90b2tlbiJdLCJzY29wZXNfc3VwcG9ydGVkIjpbIm9wZW5pZCBkaWRfYXV0aG4iXSwic3ViamVjdF90eXBlc19zdXBwb3J0ZWQiOlsicGFpcndpc2UiXSwic3ViamVjdF9zeW50YXhfdHlwZXNfc3VwcG9ydGVkIjpbImRpZDprZXkiLCJkaWQ6d2ViIiwiZGlkOmp3ayJdLCJ2cF9mb3JtYXRzIjp7Imp3dF92YyI6eyJhbGciOlsiRWREU0EiLCJFUzI1NksiXX0sImp3dF92cCI6eyJhbGciOlsiRVMyNTZLIiwiRWREU0EiXX19fX0.UP-grKXSCqcnhMN1sGj9zeMkiA_B9hjL76vTbybJ_oo0ImJRFTxz-nt0gIIytN62ytqiy_J4VfzPPFqITxjmDw

but no popup window "select credentials" is opened. The same method works fine when the same URL as in the encoded object is scanned as QR code.

[nklomp]

Oh interesting. I don't think that the flow accepting the oob param has ever been finished.

Could you elaborate a bit more on the flow you are trying to implement here? By the looks of the payload it looks like a VC part of a OID4VP flow. Given we have native support for this using the specs (version <= 11, with version 18 coming next week), I would expect a different deeplink scheme for your URL.

The wallet for instance handles roughly these deeplinks: SIOPV2 = 'siopv2', OPENID_VC = 'openid-vc', OPENID = 'openid', OPENID_INITIATE_ISSUANCE = 'openid-initiate-issuance', OPENID_CREDENTIAL_OFFER = 'openid-credential-offer

[ejossev]

Hi, yes, it is OIDC4VP request part. I tried to prepare the object as it is prepared here: https://github.com/Sphereon-Opensource/ssi-mobile-wallet/blob/develop/src/services/qrService.ts#L124-L126 (as the flow in the QR case directs it there on line 111-113).

So does it mean that I shall use openid-vc:// schema instead of com.sphereon.ssi.wallet://? Problem is, that e.g. openid schema is already used by a few other applications (e.g. Microsoft authenticator). Anyway, looking at lines 95-101, the schema is not really checked, just the URL is used. I also do not see bindings for these schemas here: https://github.com/Sphereon-Opensource/ssi-mobile-wallet/blob/6ba888b6d838d07e3fdc9df0e4610495fa2d372c/ios/SphereonWallet/Info.plist#L25 or here https://github.com/Sphereon-Opensource/ssi-mobile-wallet/blob/6ba888b6d838d07e3fdc9df0e4610495fa2d372c/android/app/build.gradle#L120

As I mentioned, the wallet starts by retrieving the request object from the backend. I assume, there is some issues with the fact, that the wallet opens the PIN screen, and this somehow supress the other popups related to processing of the OpenID4VCI/OpenID4VP flow. But I'm not a FE developer, definitely not skilled with native, so I can't find evidence for this suspicion.

[nklomp]

Hi. There are several issues being resolved in latest develop branch around scheme's. The IOS and Android scheme's mentioned above are present in the descriptors in de develop branch. Given we will release a new version to the stores any day now, these will be promoted to main soon. In current develop also some issues around intents and the lockscreen have been solved. Having said that, that is not the issue here:

The problem with the oob route is, that we need to inspect the payload before we can determine what it is. That for sure isn't currently implemented for oob, given that functionality mainly was about some early work in mapping OID on DIDComm payloads.

So for now the only route I guess is openid:// . We are happy to look at making sure that it can also start to work with oob or directly using the wallet deeplink, but given some deadlines next week, that will not happen before the end of next week.

[ejossev]

Great to hear that! I'm happy to test the new version when available :)

The problem with the oob route is, that we need to inspect the payload before we can determine what it is. That for sure isn't currently implemented for oob,

Yes, that's why I tried to pass the formatted object as is in the QR flow.

So for now the only route I guess is openid:// . We are happy to look at making sure that it can also start to work with oob or directly using the wallet deeplink, but given some deadlines next week, that will not happen before the end of next week.

As mentioned, the openid:// is crowded, at least on my phone there are multiple applications fighting for it. But I don't have problem to wait till the OOB way is done, no pressure.

[ejossev]

@nklomp So I tried the wallet version 0.1.3, and the OIDC4VP works correctly using the deep link of the form:

com.sphereon.ssi.wallet://?oob=ewogInVyaSI6ICJvcGVuaWQtdmM6Ly8/cmVxdWVzdF91cmk9aHR0cHMlM0ElMkYlMkZ2Y3ZhbGlkYXRvci12Y3ZhbGlkYXRvci5henVyZW1pY3Jvc2VydmljZXMuaW8lMkZhcGklMkZzcGhlcmVvbl9hdXRoJTJGZ2V0VG9rZW4lMkYyMjA1IiwKICJ0eXBlIjogIm9wZW5pZC12YyIKfQ==

Also, it seems that credential issuance (when not using PIN) works as well...

Maybe it was not an intention, but please, do not break it :-P

[nklomp]

Lol, okay that for sure wasn't the intention of that release. Good to know that it works though 😂