- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 3 Apr 2022 18:21:17 -0400
- To: public-credentials@w3.org
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 Sunday, 3 April 2022 22:21:33 UTC