Re: Can CHAPI survive Big Tech? (was Re: Centralization dangers of applying OpenID Connect to wallets protocols)

Hi Manu, all

Can you please elaborate on the role of authn.io? At to least to me it is not clear. I understand that it is the provider of the Javascript and the polyfills. 

- Do issuers, verifiers, and wallets have to agree on the same provider?
- Does this provider have to be authn.io?

Thanks,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 4 Apr 2022, at 1:21 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 4/3/22 10:00 AM, David Waite wrote:
>>> Yes, that is correct. The same is true for any "Login with..." solution 
>>> -- you have to load Javascript to do anything with CHAPI, OIDC, or even 
>>> DIDCommv2 on the web today.
>> 
>> All three should be similar in the requirements for the verifier to create 
>> the challenge and verify the response. OIDC and DIDCommv2 can challenge 
>> without needing javascript or polyfill by supplying an initiation link or 
>> QR code within page content.
> 
> We keep making this mistake in this thread -- that isn't an apples-to-apples
> comparison... the key phrase was "on the web today" (the presumption being
> that we were talking about web browsers since we were talking about Javascript
> and polyfills).
> 
> CHAPI is a mediator -- OIDC/* is not. The apples-to-apples comparison would be
> comparing "VPR + VC-API" to OIDC4SSI and DIDCommv2, and in that case, all
> three don't require Javascript or a polyfill.
> 
>> To adopt CHAPI you might review the polyfill, pin a version by copying it 
>> or using subresource integrity, and do an analysis on authn.io 
>> <http://authn.io> as a central party (compromise, downtime).
> 
> Note that there is no HTTP traffic that goes through authn.io -- it is a
> browser-tab-to-browser-tab protocol, that is, all communication that CHAPI
> does doesn't leave the machine and go over the network, it happens within the
> browser, from one website security zone (browser tab A) to the other website
> security zone (browser tab B).
> 
> It is also possible to run authn.io purely as a Service Worker -- that is,
> once you hit the website once to load the polyfill, you never have to hit the
> site again modulo software upgrades).
> 
> From some of the comments, it sounds like people are overestimating the
> footprint of authn.io and "how difficult it will be" to operate at scale.
> Today, it's downloading some Javascript ONCE and working from cache from then
> on... getting updates when the cache expires or upgrades are released. In the
> future, it can be downloading some Javascript ONCE and then not caring if the
> authn.io website goes down or not... because there is software installed on
> your browser (authn.io Service Worker) that will work whether you're online or
> offline, or whether authn.io is up or not.
> 
>> To adopt SIOP with a universal link invocation, you wouldn't need to review
>> javascript but you'd still do an analysis of the hosted resource behind
>> that link. It is operated by a federation/trust framework that you are
>> presumably a part of, so your evaluation. may be influenced by that.
> 
> CHAPI removes the requirement for federation and trust frameworks when
> performing wallet invocation because they are incapable of knowing which
> wallet you prefer... all they can do is impose wallet choices on you (granted,
> more of them, but you still don't have broad freedom of choice).
> 
> Now, that doesn't mean that an Issuer/Verifier can't insist that the wallet
> supports certain features, but the point is that a federation and/or trust
> framework doesn't have to exist for sensible default behaviour to exist across
> the entire ecosystem (i.e., if there are registered wallets show them,
> otherwise the RP can suggest supported wallets).
> 
> -- manu
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
> 
> 

Received on Monday, 4 April 2022 09:01:50 UTC