Re: Apple and Google's Mobile Document Request API

Thanks for pointing this out, Manu.

Most of the concerns you mention have been discussed as protocol issues
around VCs.

   - Using a client to format, present and request authorization for a
   transaction at a service provider
   - Signing the authorization request using a generic wallet different
   from the client (Sign-in with Ethereum is an example)
   - The problem of OAuth-style client credentials leading to platform
   oligopolies because neither the platforms nor the service providers
   implement dynamic client registration and their proprietary clients are
   sooo convenient.
   - The problem of well-known "certified" wallets as equivalent to ankle
   bracelets
   - The problem with denying the user the ability to delegate
   authorization as a way of mitigating our vast asymmetry of power relative
   to issuers, verifiers, and platforms.
   - Disregard for the unintended consequences of biometrics included as
   part of verified credentials and mDL.

From my user-centric perspective, the only acceptable way to design
protocols around standardized digital credentials such as mDL and VC is
based on Human Rights as opposed to the current approaches of "notice and
choice", trust frameworks, shrink-wrap contracts and market-based wishful
thinking.

My proposal for how to design protocols according to human rights
considerations is partially described in this PR to GNAP
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/434

- Adrian

On Sat, Sep 3, 2022 at 11:11 AM Daniel Buchner <dbuchner@squareup.com>
wrote:

> Something to consider: this may be a fantastic reason to rapidly expand
> our community's collective wallet capabilities/direction beyond the use of
> DIDs for the niche of credentials and into the wider decentralized app
> space. The fun part about this is that some of these vendors are
> _extremely_ unlikely to chase you into this arena because it challenges
> business models.
>
> Here's one possible strategy: if we ensure our wallets converge around
> permissioning mechanisms for robust personal datastore and ship instances
> of personal datastores within them, DWAs (Decentralized Web Apps) can
> expand the utility, reach, and stickiness of our wallets far beyond the
> credential-only parlor tricks their one-trick-pony API is capable of. If
> users adopt wallets to access DWAs, which they can do without even
> caring/knowing about credentials, it could create a beachhead install base.
> If individuals are using a wallet for engaging daily driver DWAs (real
> apps, not blockchain nonsense) getting them to subsequently use the
> credential aspects of our community's wallets becomes a lot easier.
>
> This is just one possible strategy to combat the vendor behavior Manu laid
> out (which I've sadly had to deal with first-hand), so I look forward to
> hearing your thoughts and any other ideas you have.
>
> - Daniel
>
> On Sat, Sep 3, 2022, 9:37 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> Hi CCG,
>>
>> TL;DR: Apple and Google are incubating a Mobile Document Request API
>> at W3C that creates a proprietary link between Apple Wallet and Google
>> Wallet and the web browser for the delivery of ISO mDLs.
>>
>> As many of you know, Apple and Google have been working with the
>> American Association of Motor Vehicle Administrators (AAMVA) and
>> various state Department of Motor Vehicle  (DMV) organizations to
>> deliver ISO 18013-5 Mobile Driver's Licenses (mDLs) into their
>> proprietary wallet ecosystems and then deliver those mDLs to
>> organizations like the U.S. Transporation Security Administration
>> (TSA), state law enforcement, and other potential retail/payments use
>> cases.
>>
>> The W3C Web Incubation Community Group is a community group at W3C
>> that incubates browser technologies, which is largely utilized by
>> browser vendors to signal intent and gather feedback on future
>> features in the browser. Sometimes items are incubated for a few weeks
>> before being moved into a W3C Working Group, but oftentimes they are
>> incubated for months to years.
>>
>> Apple, with support from Google, just announced the Mobile Document
>> Request API:
>>
>> https://github.com/WICG/proposals/issues/67
>>
>> The API is basically a way for a website to request a Mobile Driver's
>> License (and potentially future formats based on that format) and for
>> the browser/operating system vendor to deliver that mDL to the
>> website.
>>
>> The API is concerning because it lists "Define the native
>> communication between the User Agent and the application holding the
>> mdoc." as out of scope. That is, digital wallet selection is out of
>> scope. Also out of scope is "issuing" and "provisioning". The
>> specification focuses on delivery from a digital wallet to a website.
>>
>> For those of you that are new to these sorts of shenanigans at W3C,
>> this is a fairly standard strategy w/ the platform vendors and it was
>> only a matter of time before they took the approach with mDL (and mdoc
>> in general). The strategy is basically this:
>>
>> 1. The big tech platform vendors "incubate" a specification in WICG
>> that benefits from OS platform features that are not available to 3rd
>> parties (hardware-backed crypto keys, NFC, Secure Enclave, etc.).
>>
>> 2. After a few weeks to months of "incubating", a demonstration of the
>> specification working in Chrome and Safari is released (sometimes they
>> skip this step before asking for a W3C WG).
>>
>> 3. The vendors then "out of scope" how the OS gets the information in
>> the first place (issuance), and how the browser gets the information
>> (credential request) -- it's couched as "too difficult to get
>> agreement on the details" and it ends up being done in a proprietary
>> way per-platform.
>>
>> 4. The vendors then request a charter extension in a pre-existing
>> group with a huge number of deliverables (so the request gets lost in
>> the noise of a huge re-charter), like WebAppsWG... sometimes they
>> request a new group, like Web Payments (when it seems like there is a
>> lot of community interest in a community specification and an open
>> ecosystem -- which is then replaced by the more closed solution as
>> "the only thing the browser vendors will agree to implement").
>>
>> 5. One vendor suggests an application selection dialog (e.g., digital
>> wallet selection) and implements it -- usually Google. The other
>> vendor says they might support it in time, but then doesn't implement
>> it for years -- usually Apple. In this particular case, it looks like
>> all the vendors are just skipping right past trying to provide an
>> application/wallet selection dialog and going straight to a
>> proprietary ecosystem.
>>
>> 6. The only thing that gets to REC is the basic browser API and the
>> proprietary information exchange between the OS subsystem (e.g.,
>> Google Wallet, Apple Wallet). The "wallet selection" feature isn't
>> implemented for years by almost every vendor, and then is silently
>> dropped due to "disinterest to implement" by the remaining vendor.
>> This outcome is the best one can hope for if you want to keep
>> competitors out -- "We tried! We just couldn't get to consensus... oh
>> well.".
>>
>> In short, this looks like an OS/browser vendor play for their
>> proprietary wallet ecosystems.
>>
>> All of this should be heavily frowned upon by regulators, but they
>> don't seem to be aware of this particular trick from the large tech
>> company playbook. It's (arguably) anti-competitive behaviour under the
>> guise of a good faith effort to create a competitive ecosystem. It's
>> pretty brilliant if you think about it, you have one tech company
>> going "let's be open" and the other one going "sure, but after we get
>> version 1 shipped", and then once version 1 ships, they go "nah, just
>> kidding, wallet selection is a security risk" and the other vendor is
>> like: "well, we tried, but we can't make VendorX open up, so let's
>> just ditch the wallet selection feature 'cause, as they say, it's a
>> security risk."
>>
>> Some of us have lived through exactly this process during the W3C Web
>> Payments work. It was a really nasty experience because the above is
>> exactly what three of the browser/OS vendors did in W3C Web Payments
>> between 2010-2015. This is also why CHAPI exists; to provide real
>> application/wallet choice in a protocol and data format agnostic way.
>> It's not that the browser vendors are unaware that they could open up
>> the ecosystem to competition, they just have a very strong market
>> incentive to never do that unless some regulator steps in (like has
>> happened in the EU -- but not around digital wallet choice).
>>
>> For those of you that have been fighting to get OIDC supported for
>> mDLs; you should be concerned. The number of reasons to support OIDC
>> goes down sharply once the Mobile Document Request API goes into
>> Chrome and Safari.
>>
>> We all should and will try to engage with Apple and Google on this. We
>> should try to convince them to do the right thing and enable market
>> competition via digital wallet selection. We should also remember that
>> if the past 20 years of history is any indicator -- the OS/browser
>> platform vendors are really good at keeping those channels closed. :)
>>
>> -- 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/
>>
>>