W3C home > Mailing lists > Public > public-credentials@w3.org > September 2022

Re: Apple and Google's Mobile Document Request API

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 6 Sep 2022 08:47:38 -0400
Message-ID: <CAMBN2CRW6R9q5TPMkyZy3VWtskL9=joX=1eCNa+6Hqf7=s_bXQ@mail.gmail.com>
To: "Liam R. E. Quin" <liam@fromoldbooks.org>
Cc: W3C Credentials CG <public-credentials@w3.org>
On Mon, Sep 5, 2022 at 10:51 PM Liam R. E. Quin <liam@fromoldbooks.org> wrote:
> There are a lot of smart people in these larger companies.
> They know exactly what they are doing.
>
> In theory the role of the staff contacts and W3C team is to fight off
> such behaviours, but in practice it's rarely possible, even where the
> staff contacts have the necessary political insights.

For those of you that don't know, Liam was the W3C XML Activity lead
for 20 years. He has been central to the XML and SGML Community for
over 35 years and has helped Verifiable Credentials get to where it is
today. This man has seen some shenanigans over the years. :)

Thank you Liam, for lending more credence to this discussion.

One of the reasons these large vendors tend to get away with this sort
of behaviour is that the W3C Members let them get away with it... and
when they don't, the browser vendors just shift the work to the WHAT
WG (a largely browser vendor-only "Working Group" external to
standards bodies). That's where HTML5 lives today as the browser
vendors (arguably) became annoyed that W3C was not providing good
stewardship on the HTML standard -- they weren't completely wrong, but
this goes to show you what happens when the W3C Membership challenges
their authority.

As another case-in-point, in the W3C Web Payments work, the Working
Group (who were all new to W3C -- it hadn't had a payments activity
for over 20 years) voted against the Web Payments Community Group
proposal, and in favor of the browser vendor plan, because 1) the
browser vendors refused to implement the community group's plan, 2)
the W3C Members  (and Staff) panicked because if the browser vendors
didn't implement, the WG would be shut down, and 3) wallet selection
was promised as an outcome. It could be argued that Google made a
concerted effort to open up wallet selection, which was rebuffed by
Apple (and Edge, Mozilla, and Samsung). At present, everyone is at a
stalemate because the browser vendors probably know that there will be
formal objections to the notion of the Web Payments work as a W3C
Recommendation (because the "open standard" only supports proprietary
wallets at present).

There is a recourse -- the W3C Membership could formally object to any
work that doesn't support open wallet selection, but then the possible
outcomes are at least 1) the work moves to the WHAT WG and W3C
Membership has no say wrt. the outcome, or 2) the vendors promise open
wallet selection (but never deliver) and the W3C Membership never
ratifies the work as a global standard, or 3) the work never starts,
ensuring the proprietary wallet solutions remain the only solutions
for the foreseeable future.

CHAPI was designed to break these logjams by providing an open wallet
selection solution that  1) works in all known browsers today, 2)
doesn't require browser/OS vendor buy in, and 3) has a path to
eventually being built into the browser.

Thanks, Liam, for the public confirmation of things some of us have
experienced over the past several decades. Again, this sort of
behaviour doesn't just happen at W3C, it happens at IETF, ISO, and
just about any standards setting body you can think of. There are
strong market-driven incentives for large corporations to reduce
choice and great pressures on the people working at those
organizations to act in the best interest of the people that issue
their paycheck (and performance bonuses).

-- 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 Tuesday, 6 September 2022 12:48:26 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 6 September 2022 12:48:27 UTC