Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

On 2022-03-20 17:10, Manu Sporny wrote:
> On 3/18/22 3:27 PM, Anders Rundgren wrote:
>> According to the W3C TAG, calling native apps from the Web should be
>> abolished.
> 
> Oh, please, Anders! This is just simply not true. Proof:
> 
> https://www.w3.org/TR/web-share/

Manu, security related applications have different requirements than schemes that were mainly developed with social media in mind.

AFAICT, PaymentRequest-4-Android is the by far most capable system although it was not intended to be used in this manner :)

IMO, a Web2App API should provide a bi-directional, asynchronous channel between the App and the invoking Web page.  Some self-proclaimed security experts claim that this would open a can of worms, ignoring the fact that most existing solutions including URL handlers already supports this capability, albeit in a much more quirky (and less secure) OOB way.
The security context (TLS certificate path) of the calling Web page must also be available for the App in question.
In addition, it should also work in a cross device scenario as I outlined in another posting.

Having advocated this for 8 years+ to no avail, I think we can safely dismiss this topic altogether and stick to our favorite "band-aid" solution whatever that might be.


It is also important to understand W3C's approach to wallets which works like this in a C2B payment scenario:
- You take up your plastic card and input the core data in a merchant UI
- The merchant uses this information to locate the issuer bank (https://github.com/cyberphone/doc/blob/gh-pages/payments/review-secure-payment-confirmation.md#integration)
- The issuer bank returns the FIDO key identifier associated with the account data
- The browser built-in payment application is then used with the FIDO key to authorize the payment request

In addition to being extremely inconvenient, I'm puzzled by the fact that the WebAuthn folks are happy standardizing a system that already on paper violates GDPR.  Merchants do not need card numbers, they need assurances that they will get paid.  Apple solved that years ago by building on a concept established in the 90'ties.

Thanx,
Anders


> 
> You can share data with native apps today on Edge, Chrome, Safari, iOS,
> Android, Samsung, and Firefox:
> 
> https://caniuse.com/?search=web%20share
> 
> ... and there is movement afoot to enable PWAs and Websites to be share
> targets as well:
> 
> https://w3c.github.io/web-share-target/
> 
> If the latter were to happen (with a few minor tweaks), it would solve the
> "invoke an open ecosystem wallet" problem for both web and native.
> 
> It'll take a few years to get the latter, but the former "calling native apps
> from the Web" became a reality two years ago. The next version of CHAPI uses
> this feature to send/receive Verifiable Presentation Requests w/ native apps, btw.
> 
> I'll also note that this mechanism is not susceptible to the same browser
> vendor market pressures that were included in Orie's rant about browser
> vendors and surveillance capitalism. The APIs above are not at risk in the
> same way that OpenID redirects and openid:// protocol handlers are at risk.
> 
> -- manu
> 

Received on Monday, 21 March 2022 06:40:46 UTC