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

Exactly. That's why I said our approach was complementary. This is the
great thing about open source implementations of standards. App platforms
like Azure or Ethereum are big tech that's constrained by the very nature
of their business to just running code. They're more like a telecom "common
carrier" than a big tech platform such as Facebook. The current dust-up
around Tornado Cash is a good example of the separation of concerns between
the big tech like GitHub and big tech like Ethereum or Azure.

Adrian

On Fri, Sep 2, 2022 at 10:06 AM Benjamin Young <byoung@bigbluehat.com>
wrote:

> Just catching up with this thread, but I did want to correct something
> below:
>
> “Unlike chapi.io, we use a GitHub repo…”
>
>
>
> It looks like all of chapi.io’s site contents and various demo issuer,
> verifier, and wallet code are all open sourced under this organization:
>
> https://github.com/credential-handler
>
>
>
> License looks to be BSD-3-Clause throughout (from a quick check of a
> handful of them).
>
>
>
> So, no reason the chapi.io work couldn’t be reused in the same way you
> described.
>
>
>
> Go team? 😊
>
>
>
> *From:* Adrian Gropper <agropper@healthurl.com>
> *Sent:* Thursday, September 1, 2022 12:30 PM
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* public-credentials@w3.org
> *Subject:* Re: Can CHAPI survive Big Tech? (was Re: Centralization
> dangers of applying OpenID Connect to wallets protocols)
>
>
>
> This is a rich thread with "survive big tech" as the subject. Our Trustee
> Community project is also trying to provide a simple and reliable user
> experience on top of Verifiable Credentials. Our approach is not an
> alternative to CHAPI but may be interesting in the context of this thread.
>
>
>
> Trustee, like CHAPI, depends on complex open source code to manage storage
> of sensitive information. Unlike chapi.io, we use a GitHub repo linked to
> a Digital Ocean App Platform. If reliability or security becomes an issue,
> we could substitute any other (big tech) app platform (Apple, Microsoft,
> Heroku) by simply moving the domain. In this arrangement, trust is shared
> across two standards-based big tech entities and whatever auditors choose
> to certify the source code as identified by the (GitHub) commit hash.
>
>
>
> Any community or individual is able to fork the HIE of One repo and choose
> other big-tech to run the web services. Independently, anyone can certify
> the code. It's up to individual users to join a community if they don't
> want to run the code themselves.
>
>
>
> https://github.com/HIEofOne/Trustee-Community
>
>
>
> Adrian
>
>
>
>
>
>
>
> On Thu, Sep 1, 2022 at 10:39 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
> 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/
>