Re: [EXTERNAL] [jfraichot@learningmachine.com] Re: Can CHAPI survive Big Tech? (was Re: Centralization dangers of applying OpenID Connect to wallets protocols)

Hi all,

I’ve been catching up on CHAPI and I also a few questions lingering, but first thanks to anyone involved in the development process, it is a very smooth and easy experience to set CHAPI up. My only feedback would be to provide some Typescript types to make it easier still to figure out the available APIs and parameters’ shape.

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

Indeed, from somewhere in the conversation, Manu you mention that authn.io should be the official relying central piece to CHAPI and that it will belong not to Digital Bazaar anymore but to a group.
What do you mean in those conversations by:

  *   Going to production by the end of the year? Isn’t authn.io ready for use at this point?
  *   Could you elaborate on the shape of the entity that will manage authn.io? Or at least is there a video/presentation/demonstration/discussion to which you could point me to?
  *   I understand the risk of letting organizations run their own mediator piece, but I feel having a single point of failure could also be problematic. Why should authn.io be the only official mediator?
  *   On the github page: https://github.com/credential-handler/authn.io#credential-mediator, it mentions: “This software plays the Credential Mediator role described in Credential Handler API<https://w3c-ccg.github.io/credential-handler-api>“. But I was not able to find a section describing the Mediator (at least with ctrl+F for “mediator” in the page). Did I miss it? Are there resources to which I could refer for a better philosophical understanding of the Mediator need, where it’s coming from, etc?
  *   I started digging into the code but I see the implementation is quite rich already so I got a bit lost. But “it is a browser-tab-to-browser-tab protocol”. I am trying to figure out how storage works - is there somewhere that explains how the Mediator works under the hood? I’d like to get up to speed on the technical side.

> 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).


  *   Related to the previous question, this aroused my curiosity. Is there more explanation on how  to get that setup somewhere?

Thank you,

Best

Julien Fraichot



On 4/4/22, 11:04, "Nikos Fotiou" <fotiou@aueb.gr> wrote:
CAUTION: This email originated from outside of Hyland. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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<mailto: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><http://authn.io%3e> 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/
>
>


-----------------------------------------  Please consider the environment before printing this e-mail -----------------------------------------  

CONFIDENTIALITY NOTICE: This message and any attached documents may contain confidential information from Hyland Software, Inc. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for the delivery of this message to the intended recipient, the reader is hereby notified that any dissemination, distribution or copying of this message or of any attached documents, or the taking of any action or omission to take any action in reliance on the contents of this message or of any attached documents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, at +1 (440) 788-5000, and delete the original message immediately. Thank you.