Re: Apple and Google's Mobile Document Request API

On Sat, Sep 3, 2022 at 2:10 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
> 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?

As you said, Web Payments is not wildly successful today. The Payment
Request API and Payment Handler API have yet to reach REC status after
7 years of Working Group activity -- Microsoft, Samsung, Mozilla, have
all decided to not implement it so far.

We should keep in mind that failing to create a standard is of benefit
to the OS/browser platforms. Directing people through the Google Pay
and Apple Pay Apps because a wallet selection mechanism doesn't exist
in the browser constrains choice. It enables them to charge more basis
points (a percentage of revenue) on each transaction through their
native apps. Apple Wallet/Pay has a large market share for financial
transactions at the point of sale, again, there isn't much incentive
to open that payment channel up (proprietary Apple Pay / Google Pay at
the point of sale) to competition.

> Can you also describe other times this playbook has been employed and the outcomes?

Variations of this playbook was/is (arguably) employed for Adobe Flash
/ SVG, h.264/VP8, Encrypted Media Extensions, WebRTC, Web Payments,
FLOC, AMP, FedCM, mDL/mdoc/VCs... across W3C, IETF, ISO, etc. This is
not something that's isolated to W3C, in fact, spreading the
initiative between multiple standards bodies increases the chances of
its success (a failure to standardize). For example, ISO mDL + W3C
Mobile Document Request API almost ensures that most people will not
be able to engage at ISO in the same way they can engage at W3C.

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

My experience has been that the typical argument used by the browser
vendors is: "Let's start small and focused, and generalize once we
have version 1.0 done." That, of course, rarely happens because
version 1.0 falters -- 'cause it's a trap. What's really needed, and
what CHAPI does, is create an arbitrary data format and protocol
agnostic pipe between two systems (web-to-web, app-to-web,
web-to-app). That is the desired end-state, IMHO, but the browser
vendors seem loath to create a group with such a broad remit.

Web Payments -- "This is about registering payment instruments and
using those to pay. We don't deal with identity, or credentials, or
loyalty cards, or coupons, or anything else. This WG is just about
payment. Maybe we'll generalize this data sharing interface if we're
successful."

FedCM -- "This work is about identity federation and login, we are
focused on removing 3rd party cookies as used for login. We don't deal
with credentials, or payments, or arbitrary data movement between
websites.  Maybe we'll generalize this data sharing interface if we're
successful."

Mobile Document Request API -- "This work is about requesting and
presenting mDLs and, eventually, mdocs. We don't deal with any other
data format.  Maybe we'll generalize this data sharing interface if
we're successful."

... and so on. It's all a bit misguided. Yes, you want to focus on
critical use cases, but not to the detriment of a more generalized
solution. Unfortunately, we have multiple examples (above) of there
being a focus on point solutions rather than generalized solutions.
It's difficult to determine if this is being done on purpose, or by
accident. Given that many of the people advising this work have been
around at these large companies for 10-20 years, it's hard to believe
that this is all an accident that it keeps happening. :)

-- 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 Monday, 5 September 2022 19:56:13 UTC