Re: Apple and Google's Mobile Document Request API

+1 Daniel - definitely thoughts worth considering


Mike Prorock
mesur.io

On Sat, Sep 3, 2022, 11:11 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/
>>
>>