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

On Thu, Sep 1, 2022 at 8:54 AM Julien Fraichot
<Julien.Fraichot@hyland.com> wrote:
> 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.

Hey Julien, I'm glad to hear that setting up CHAPI was a smooth and
easy experience. That has been the goal from the beginning and we're
getting reports back from implementers that it only takes a day for a
single developer to get a proof of concept working, and a few days
more to get a credential stored and delivered. We're interested to
hear from those integrating with CHAPI to understand if we can improve
the experience for you.

> My only feedback would be to provide some Typescript types to make it easier still to figure out the available APIs and parameters’ shape.

We'd love to make progress on that. PRs are welcome as it's been
difficult for us to determine what changes are needed for Typescript
(we don't use Typescript). Recently, there have been challenges
introduced with the switch to ESM6 and the way Typescript works. If
you could raise an issue, or a PR to help us help you, that would be
very much appreciated. :)

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

Yes, correct. We created and operate CHAPI today, but have a desire to
share the load with the community. The only issue to date are
community members stepping forward to take on more financial and
operational responsibility. To be clear, this isn't a requirement for
CHAPI to work -- Digital Bazaar uses CHAPI in a production capacity
today and has operated the system for the past 7 years in that
capacity. CHAPI isn't going anywhere, Digital Bazaar is committed to
operating the infrastructure (which is quite inexpensive to run) for
the foreseeable future.

> Going to production by the end of the year? Isn’t authn.io ready for use at this point?

You can rely on authn.io for pilot/production systems at this point.
We do want to make it better by having a dedicated 24x7x365 datacenter
staff to operate the system. It's never failed before  -- it's just a
static website serving static pages -- but we can always do better,
and so we're making the investment to have a dedicated, global
datacenter staff operate the system.

> 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?

There is no presentation yet, as we'd have to have organizations that
are willing to put in the legal, financial, and operational time to
help us run authn.io. To date, organizations have been happy to just
use CHAPI and not take on that additional burden, so we continue to
operate the site for free, on behalf of the community. The shape of
the entity will largely depend on the group of organizations that want
to participate in the operation of authn.io and the CHAPI
infrastructure.

At present, we believe that a loose consortium composed of simple
legal agreements to be enough for a global, production ready system.
We could also do something more formal and house the work in the Linux
Foundation (or a similar foundation). The thing that makes CHAPI a bit
different is that the open source software requires some
infrastructure for people to use (the authn.io website). It's just a
simple static website, but someone has to make sure that website is up
24x7x365, which is not a difficult task with modern data centers.

> 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?

It's for a technical reason -- the browser same-origin model does not
allow you to share storage between multiple domains. CHAPI has to
store wallet registrations in some web domain (at present, that's
authn.io). If organizations ran their own CHAPI mediator, wallet
registrations on other mediators wouldn't show up and that would
result in a split in the ecosystem. It would be really bad if that
happened and would cause active harm to the CHAPI open wallet
ecosystem. Some large companies have tried to do this with CHAPI and
we've asked them to stop and thankfully, they've listened (or failed
to try and fork the ecosystem because their product failed).

So, there has to be a domain in the browser where everyone can
register their digital wallets and that only has to exist as long as
CHAPI isn't built into the browser. Once CHAPI is built into the
browser, that authn.io domain will no longer be necessary. That said,
it will take many years to do that transition and until then, authn.io
will have to stay around.

> 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“. 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?

A "Credential Mediator" is what the Credential Handler API specifies:

https://w3c-ccg.github.io/credential-handler-api/

There is an (old and possibly outdated) presentation about it here
that we did to CCG in 2020:

https://docs.google.com/presentation/d/1_h0-OKMpUJnEMAMZLgZl_ic726RSXtfKSgGyf1ksiag/edit

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

That's a good start to a high level summary, but is still inaccurate:

If I had to summarize it, I'd say that CHAPI provides a way for a Web
domain to request data from another domain, which can be either
another website, or a native software application. Verifiable
credentials are just one kind of data that can flow over CHAPI. CHAPI
respects an individual's right to choose which wallets/software they
use instead of having the choice forced on them by a website (e.g. you
MUST "Login with Google/Apple/Microsoft/etc.").

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

No, there is no concise explanation of how CHAPI storage works -- it's
buried in the code. Many people that use CHAPI tend to not look that
deeply into all of the browser magic that has to happen for CHAPI to
work across all known browsers in the market at present. :) -- it's
exceedingly difficult to get a polyfill to work across all modern
browser implementations and getting to a consistent storage story is
different in Safari, Chrome, Chromium, Edge, Samsung Internet, and the
myriad of other browsers out there. Sometimes you can use 3rd party
cookies (Google), sometimes you need to use 1st party cookies (Brave),
sometimes the browser changes its mind using some artificial
intelligence algorithm (Safari)... and so on. It's complicated and
ever changing -- CHAPI has been constantly adjusting to the landscape
over the past seven years and we expect that to continue as the
browser engines change their security models. :)

Some of the CHAPI developers might need to correct me if I get this
wrong, but the only real storage that authn.io needs is the wallet
registrations (it needs to know which pieces of software the
individual has said that they want to use to respond to requests for
information (such as Verifiable Credentials)). There are other
complexities around 1st party storage and 3rd party storage that I
elaborated upon above... but writing that up tends to be a futile
exercise as it  can change from browser release to browser release.

>> 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?

We haven't enabled the Service Worker functionality yet, but plan to
do so before (or shortly after) we go into a fully managed production
environment for authn.io. It's a feature that has questionable
upsides.

There is extra complexity to the Service Worker approach, and that
approach really only kicks in when:

1. You have lost your Internet connection, at which point the issuer
or verifier you're trying to contact is probably offline, unless they
have a service worker installed... and if that's the case, it's highly
unlikely that they have an offline verification mode that doesn't hit
a server at all, and if they do, their application probably can't
effect any change back at the datacenter because... you are totally
offline and can't contact anyone because your Internet connection is
down. :)

2. The authn.io static website is down, which is exceedingly unlikely
because we have 7+ years of operational experience. Static sites
running out of modern datacenters rarely go down, and if they do, it's
often for seconds to minutes.  It's questionable if we should increase
complexity by adding Service Workers to solve a problem we haven't had
in the last 7 years. The argument is more theoretical than practical
at this point in time. :)

At the end of the day, Digital Bazaar depends on authn.io for all of
our paid customer work. If it ever goes down, our customers become
very unhappy, so there is a very strong incentive to keep it up and
running (as we have over the past 7+ years). That said, we would
welcome other organizations that use it sharing in the financial and
operational load -- while we might never need that to happen, we'd
like to make this a more community run enterprise.

For those that would like to play around with CHAPI, we recently
launched the CHAPI Playground:

https://chapi.io/

It contains an issuer / wallet demonstration here, along with a few
demonstrator VCs that you can get issued to you and placed in your
digital wallet. If you register any other digital wallet, like the
Hyland one (Julien), you'll show up in that list and should be able to
receive the VC into your digital wallet as well:

https://playground.chapi.io/issuer

Sorry for the long email, but I hope that answers your questions,
Julien. Let me know if you have any more, I'd be happy to do my best
to try and answer those as well.

-- 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 Thursday, 1 September 2022 14:36:24 UTC