Re: Apple and Google's Mobile Document Request API

Why the surprise though? big tech has always been in the business of skimming the markets at speed and scale. They have always done the 20% work needed to cover the 80% viable markets and shovelled the remaining 80% work over the fence to the 20% public interest groups. Failure is at W3C (and similar) system/governance level, where such behaviour is tolerated and not acted upon? What are the incentives of W3C that allow this tacit accomplice syndrome?



As per a popular book (Switch), we can either shape the road or kick the elephant. Shaping the road is a call for more of us talking to policy makers, building bridges with like-minded public technologists (Singapore and Canada come to mind) and making all this good thinking accessible to decision makers and influencers at D7, G20 circles. Before this is waved away with a smile, the contrarian (and right/correct) thinking is dearly lacking in not just the visible part of these circles but the cohorts of staff who build the collateral for their events, discussions and gatherings.



Looking at this pure gold thread - it is on a mailing list, attended (mostly) by rebels. Zoom out enough and you will see a mouse screaming at the ocean waves. [if anyone is offended by this observation, assume I speak of myself and move on, I have neither time nor desire to convince you otherwise]. Funding is not where we are strong, and we should not seek to excel at it imho. This is not our game, so a better game need be crafted, in a way.



In my view more of these conversations should be surfaced in digestible formats: articles, blog posts, whitepapers, talking points and references. Append to that readiness to talk to public officials or spread the word at events - this is where the power of many (of us) starts making a difference in comparison with the few abusing the system with templated persistence. If we let this continue to unravel exclusively here, we can all spare keyboard strokes and effort, as none of us alone will climb high enough to inflict that needed change in thinking.



Take this conversation out in the world. I found inspiration in the effort of Timothy Ruff earlier today: https://rufftimo.medium.com/web3-web5-ssi-3870c298c7b4



Cheers,

K


From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tuesday, 6 September 2022 at 14:51
To: Liam R. E. Quin <liam@fromoldbooks.org>
Cc: W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Apple and Google's Mobile Document Request API
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 Wednesday, 7 September 2022 10:03:36 UTC