- From: Nikos Fotiou <fotiou@aueb.gr>
- Date: Mon, 4 Apr 2022 12:01:34 +0300
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: public-credentials@w3.org
- Message-Id: <2ED367F1-913E-4357-AC5B-6E1F0DC9224C@aueb.gr>
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/ > >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 4 April 2022 09:01:50 UTC