Re: CHAPI Playground now supports VC-API

On 2023-08-27 23:49, Manu Sporny wrote:
> On Fri, Aug 25, 2023 at 10:28 AM Anders Rundgren
> <anders.rundgren.net@gmail.com> wrote:
>> I'm not convinced that this is a viable solution because deep links:
> 
> Hey Anders -- to be clear, the solution uses "app/universal links",
> not "deep links" and not "protocol scheme handlers". You can read more
> about the difference here:
> 
> https://developer.android.com/training/app-links
> https://developer.android.com/training/app-links/verify-android-applinks
> 
> It requires publishing a file like this from your domain:
> 
> https://domain.name/.well-known/assetlinks.json
> 
>> - Do not provide the invoking web page's security context.  *PHISHING WARNING*.
> 
> The request that the app receives does indeed contain the security
> context to which the response will be sent. This is documented here:
> 
> https://chapi.io/developers/wallets/native/#verifiable-credential-storage
> 
> Search for the following text in the link above: "The request value is
> URL encoded."
> 
>> - Do not provide a response at the JS level, effectively forcing you to use awkward OOB arrangements
> 
> Yes, that is unfortunate, but is where native apps are today.
> 
> I'll also note that CHAPI also supports a fully in-browser flow for
> digital wallets that support web-based views. In this mode, there is a
> response at the JS level and the individual isn't taken away from
> their workflow on the original website (as you state above)... no
> awkward OOB arrangements.
> 
>> The only solution that actually support these desirable properties is Android's implementation of Payment Request:
> 
> Yes, well, we all know of the failings of that initiative since we
> lived through it. :)
> 
> There is work being done to try and provide CHAPI with native APIs to
> provide a more browser-integrated flow:
> 
> https://github.com/fedidcg/FedCM/issues/374#issuecomment-1402862891
> https://github.com/WICG/identity-credential/issues/12
> 
> ... but unlike what happened w/ PaymentRequest, we don't have to wait
> around for this stuff to be built into the browser for it to be useful
> today. Today, CHAPI works on every modern browser that we know of,
> with or without 3rd party cookies enabled, supports web-based digital
> wallets and native digital wallets, as well as multiple protocols
> (Browser, VC API, and OID4VCI) (as well as whatever data formats each
> of those protocols support).
> 
> Does that address your concerns, Anders?

I'm not 100% sure but I believe "PaymentRequest-4-Android" and "app/universal links" differ with respect to the invoking web page.  The latter is AFAICT only designed to verify that the wallet is genuine.

Without https://web.dev/i18n/en/android-payment-apps-developers-guide/#toplevelcertificatechain I believe applications are vulnerable to phishing.  In my applications, attestation signatures include a hash of the "merchant" certificate.  Then the RP can be assured that there was no "intermediary".  The reason to why app links do not have this fundamental feature is because they were not developed for supporting security applications.  Google et al see WebAuthn as the only legitimate security application for the Web and [silently] frown at using PaymentRequest as a secure proxy between the Web and the native world.

As a consequence, I believe most mobile banking apps and national on-line identity solutions are susceptible to phishing!

Anders

> 
> -- manu
>

Received on Monday, 28 August 2023 06:27:41 UTC