Re: Apple and Google's Mobile Document Request API

On 2022-09-03 20:10, Mike Jones wrote:
> Thanks, Manu, for this analysis.  It’s certainly sobering for those of us working on building open credentials ecosystems.  Since you’re identifying a playbook that’s been employed before, I’m curious how that’s worked out in practice and what we can learn from it.
> 
> For instance, it doesn’t seem like the Web Payments work has taken the world by storm.  Is that due to flaws in the playbook or flaws in the underlying approach (or both)?  Or is my perception off, and it’s wildly successful?

Mike, your observation is correct, the Web Payments API never not got much traction outside of Google's and Apple's proprietary implementations.  The are many reasons for that, including that MSFT left this activity years ago.

W3C's latest payment project (SPC), is as you know based on FIDO/WebAuthn which may sound like a great plan until you realize that it is at odds with most other developments in the payments world, where "wallets" has become the norm.  That Google's and Apple's proprietary solutions build on wallets does not come as a surprise.

When I joined the Web Payment activity as observer/lurker I did the assumption that payments is 50% about politics.  This turned out to be huge understatement.

Is there any hope?  Sure, but probably not via the W3C.  A brave and leading browser vendor must first show that it is possible [*].  MSFT? :)

Best,
Anders

*] There are AFAICT no *technical* problems combining FIDO with wallet meta-data including supporting account-2-account transactions of the kind that non-FIDO solutions already do.

> 
> Can you also describe other times this playbook has been employed and the outcomes?
> 
> One of the odd things to me about the proposed approach is that it’s mDoc specific – rather than being credential-format independent.  Do we have any insights into why that is?  By contrast, the OpenID for Verifiable Credentials specs are credential-format independent – able to use W3C Verifiable Credentials, mDocs, and other credential formats.  (You can read about this in the whitepaper OpenID for Verifiable Credentials <https://openid.net/wordpress-content/uploads/2022/06/OIDF-Whitepaper_OpenID-for-Verifiable-Credentials-V2_2022-06-23.pdf>, which opens with an approachable 1.5 page Executive Summary.)
> 
>                                                         Sincerely,
> 
>                                                         -- Mike
> 
> *From:* Orie Steele <orie@transmute.industries>
> *Sent:* Saturday, September 3, 2022 10:28 AM
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* W3C Credentials CG <public-credentials@w3.org>
> *Subject:* Re: Apple and Google's Mobile Document Request API
> 
> Thanks for taking the time to write this up.
> 
> A few thoughts:
> 
> Apple and Google have no incentive to open this kind of protocol up, and W3C has no incentive to stop them from doing what they are doing... The W3C is not a regulator, and in my experience regulators are not even attending W3C WGs, or commenting on activities related to competition in this space... Beyond that, Apple and Google may have folks on the board of directors for W3C before this incubation work even finishes.
> 
> There are legitimate use cases for device bound human identity... And device identity, and a lot of them require interfaces like this, or that are a superset of this.
> 
> Let's document some of the use cases for such an API.
> 
> A few interesting ones:
> 
> 1. Prove you are an accredited investor.
> 
> 2. Prove you are vaccinated (recently).
> 
> 3. Prove you are eligible to purchase drugs / alcohol.
> 
> 4. Prove your status regarding criminal history (sex offender, convicted felon, etc).
> 
> 5. Prove you are eligible to vote.
> 
> 6. Prove you have an active software license.
> 
> 7. Prove you are TSAPre / Global entry authorized.
> 
> 8. Prove your dog is vaccinated.
> 
> 9. Prove you have a security clearance.
> 
> 10. Prove you are a citizen.
> 
> 11. Prove you are a member of a protected class.
> 
> 12. Prove you are under witness protection.
> 
> 13. Prove you have not recently published misinformation.
> 
> 14. Prove you have no recent CSAM alerts.
> 
> 15. Prove you have an account with Apple/Google, or are using an approved device.
> 
> 16. Prove you have / have not recently traveled to Israel / Palestine.
> 
> I'm ok with many of these capabilities, and some of them reflect credentials that we all deal with today...
> 
> The question is really, for other device + os combinations... Such a Qualcomm + Android or Windows + Qualcomm, or Arm + Linux, Intel + Linux, AMD + Linux...
> 
> Will these platforms be treated equally?
> 
> Will the owners / controllers / data subjects of these devices be treated equally?
> 
> Will chrome, edge, brave, safari, firefox support "bring your own device" or "bring your own wallet"?
> 
> Will TSAPre become Google or Apple Precheck?
> 
> Will the state department require an Apple or Google phone for international travel?
> 
> Building an open ecosystem, is far less profitable than building a choke point and adding credential types one by one...
> 
> As Manu noted, the market pressure for Google and Apple to do this is enormous... They are basically required to take this route.
> 
> I don't think this API can be stopped, the best we can hope for, is that it can be made as open and interoperable as possible, so that a healthy competitive market can thrive and grow.
> 
> If competition in this space is not protected, consumers will awake one day to find that Google and Apple have essentially merged into something akin to sci-fi cyberpunk mega corporations we all love: Weyland-Yutani, Cyberdyne Systems, Tyrell Corporation, Wallace Corporation! : )
> 
> I love Apple and Google... I don't want to see them become hated for smothering an open ecosystem for digital identity, credentials and payments...
> 
> I hope mDoc and mDoc request API can be made to support an open world model, where currency, identifiers and credentials about subjects can be controlled by subjects on devices chosen by subjects... Where the subjects have more than just 2 choices...
> 
> This is an observable property for these technologies... You can see how it's going for browsers and mobile operating systems...
> 
> If we are talking about what a chrome only web is looking like now... 10 years from now, will we be talking about chrome only identity, payments and credentials?
> 
> It's time for Microsoft, Amazon, Meta, Tesla, Tencent, Samsung, Alibaba, Oracle and others to embrace an open world model.
> 
> To compete to provide services without vendor lock... To work with Apple and Google, to protect a healthy competitive market.
> 
> I hope this API and the data models it moves are made open by design, out of respect for consumers, and not by the force of regulators.
> 
> Regards,
> 
> OS
> 
> On Sat, Sep 3, 2022, 9:38 AM Manu Sporny <msporny@digitalbazaar.com <mailto: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 <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/ <https://www.linkedin.com/in/manusporny/>
>     Founder/CEO - Digital Bazaar, Inc.
>     News: Digital Bazaar Announces New Case Studies (2021)
>     https://www.digitalbazaar.com/ <https://www.digitalbazaar.com/>
>

Received on Sunday, 4 September 2022 07:20:49 UTC