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

On 2022-03-22 0:06, David Waite wrote:
> On Sun, Mar 20, 2022 at 2:32 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     On 2022-03-19 23:52, Tobias Looker wrote:
>      >  > Can you say more about those multiple ways? If I'm understanding correctly, there is just one mechanism that SIOP supports, and that is through a custom url protocol link. Is that not the case?
>      >
>      >
>      > I guess it depends on what you constitute as being different in this context? What I meant here was the options that DW listed.
>      >
>      >
>      > 1. Local Invocation via URL schemes or platform-registered HTTPS URL (e.g. universal links, app links)
> 
>     Or by misusing PaymentRequest which is a pretty good replacement for the eternally missing Web2App API:
>     https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf <https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf>
> 
> 
> This seems to use URL schemes or claimed URLs itself, without any special platform level support (e.g. listing applications which advertise a certain characteristic for the user to choose). So it should have the same trade-offs today, with a different API on front.

Since you are advocating SIOP, I can only try to explain why I believe that PaymentRequest-4-Android is the currently by far most powerful way interacting with native apps from the Web.
- It provides the security context of the invoking Web page to the App
- Apps can return a result to the invoking Web page
- Apps run in the context of the invoking Web page
- The browser functions as a selector in the (unlikely) case you have multiple Apps supporting the same (claimed) URL/identifier
- Apps have full native mode application access to the OS

Regarding the ability for the user to choose, this is currently extremely unusual, if available at all.  Existing systems rather work like WebAuthn, either you have it or not.  If not, you are excluded.

That is, a URL/identifier represents a specific technical solution or standard which the RP understands.  This does AFAICT not limit innovation or discriminate vendors.  RPs may also support multiple solutions which (if registered) are offered for user selection by the browser.

To put things in perspective, the WebAuthn folks have settled on a single hardcoded identifier for their [sort of] payment wallet.


If people want, we could try to make a table of features for the various schemes.


Anders

Received on Tuesday, 22 March 2022 05:21:45 UTC