Re: Apple and Google's Mobile Document Request API

And who is going to fund engaging with all these cute elite east coast
think tank things that now care about "digital public goods" - about our
work and efforts?


On Mon, Sep 5, 2022 at 1:32 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> Standards as fundamental as DID and VC cannot solve societal problems
> unless they're part of a broader effort to support digital public goods:
> https://www.brookings.edu/research/can-open-source-technologies-support-open-societies/
>
>
> Adrian
>
> On Mon, Sep 5, 2022 at 3:59 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> 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/
>>
>>