Re: Sustainable Verifiable Credentials

Web browsers consume tremendous resources, and many web applications are
needlessly wasteful.

I filed https://github.com/w3c-ccg/traceability-vocab/issues/870 to gather
feedback on how we might attempt to address this topic from the wider W3C
community.

We already have interoperability and conformance tests, which we might be
able to leverage to get this off the ground faster if there is interest.

The document that I referenced at the start of this thread makes many
excellent recommendations that apply to Verifiable Credentials, which can
also be implemented in ways that are wasteful.

For example, this document still recommends bitcoin based decentralized
identifiers: https://identity.foundation/jwt-vc-presentation-profile

It seems like some are suggesting that attempting to remove wasteful CPU
and memory usage is "green washing", I don't agree.

To make my position clearer, I think JSON-LD processing prior to
verification does not align with sustainable software development
practices, because it is an expensive operation that can time out or run
for a long time and then fail later at signature verification time.

A more sustainable approach would be to check the signature on the bytes
first, and then do graph processing when you need the graph data model.

This lines up with "use a little power first", and then "use more power
when it's safe to do so".

For the case where verification succeeds, you still get the graph data
model, and you don't waste time (and energy) processing tampered data.

This is similar to the other recommendations in the document, like code
splitting and tree shaking, where we try to avoid doing work, until it is
needed.

Additionally, JSON and other text formats consume extra storage and network
resources when compared to binary formats.

I think it would be good to see that consumption visualized, so that the
market can see the true cost of the various digital credential formats
being proposed by ISO, IETF and W3C.

I recognize there are lots of W3C member organizations that are committed
to technologies that might not perform well on these guidelines.

I say this as a JS developer who often includes dependencies for
convenience that are not necessary to the function of the program... That
does not make it right to do.

I'm trying to improve my GoLang and Rust, but it's hard to code when there
is so much standard debate to be done.

There was some threatening related commentary shared on the member list
recently regarding antitrust and competitive testing / evaluation.

Gaming tests, by excluding competing solutions, or biasing the evaluation
of the performance of competing formats sounds like something that we
should be vigilant about, given that it can artificially constrain digital
markets.

There are parts of this topic related to competitiveness that feel like
they overlap with the sustainability topic, and in fact, previous formal
objection debate called out sustainability "values" as something the W3C
should not be focused on... and I disagree with that... It should be
debated. In other words:

When is choosing "expensive and complicated" worth it over "sustainable and
cost effective"... What "values" justify "additional cost"... Complexity
and cost (power, time and money) all impact price.

Using a standards process to impact the price of securities, products or
services... Should concern all of us... W3C is not law enforcement or a
regulator, but they read our lists, and W3C cares about how it is perceived
in this regard.

I personally don't want to see a highly competitive low cost market for
"privacy destroying surveillance tech"... On the other side, reducing
complexity and cost for blue team builders seems worth sacrificing some
academic purity or other values over... I'd rather see clean water sold to
a billion people, than isotopically pure water sold to a million... We
should aim at having a large impact on improving privacy and security.
Complex and unsustainable approaches detract from that mission.

One could argue that energy consumption from WebGPU could cause the web to
impact the environment negatively in service of local machine learning or
other missions, the point of debate at W3C is to discuss if the proposed
solutions are "worth it", not to dismiss them without evidence... Hence the
focus on evidence based approach in
https://w3c.github.io/sustyweb/#have-an-ethical-and-sustainability-product-strategy


This was discussed during the DID Core formal objections, and positioned
politically in both directions... The objectors asked for evidence, the
proponents refused and claimed political bias / greenwashing / anti
competitiveness.

In summary, people argued Bitcoin was "worth it" because it solved for
"decentralization best", others disagreed...

The objections were not resolved, they were overruled... After 9 months, by
Sir Tim, who won't be able to do that next time.

I expect folks who felt strongly about them, still hold those feelings....
Recent debate on this list, showed support for proof of stake over proof of
work, based on its reduced impact on energy consumption, but that can
come with a trade off that can cause conflicts with securities laws... All
systems design is a balancing act.

Debate now will help strengthen responses to future formal objections, or
we can wait and see.

Based on the previous experience I don't recommend we take that approach.

It might never be possible to agree on W3C values regarding sustainability,
but I don't mind being a broken record that CPU and Memory are not "free"
and they are not "neutral" in their impact on our planet, and we can and
should strive to be better at leveraging them to protect the values we
share.

Regards,

OS



On Fri, Sep 8, 2023 at 9:01 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Thu, Sep 7, 2023 at 10:21 PM Orie Steele <orie@transmute.industries>
> wrote:
> > The VCWG could recommend against wasteful cryptographic operations or
> dependencies that consume more CPU than is needed to sign or verify.
>
> Ah yes, the good 'ol "TLS is too expensive to implement at scale"
> argument, which has been repeatedly debunked through various
> technology cycles:
>
> http://highscalability.com/blog/2011/2/10/dispelling-the-new-ssl-myth.html
>
> The argument goes "Cryptography X is too expensive to implement, so we
> should just keep doing what we've always been doing!"... which
> presumes that two technologies are exactly the same, which they're not
> (as has been said earlier in this thread).
>
> To be clear, we have implemented a variety of the VCDM securing
> mechanisms at scale, in production, and the time it takes to secure a
> VC is an insignificant rounding error compared to the time taken
> running on top of multiple layers of virtualization in cloud
> environments, and communicating w/ other HTTP APIs, doing database
> updates/calls, and running business logic.
>
> This is a textbook case of trying to optimize the wrong thing and it's
> coming off as political in nature. You might let everyone know that
> you're the lead editor on a specification that would benefit from this
> sort of "recommendation against wasteful cryptographic operations".
>
> Furthermore, you might as well suggest that we stop using interpreted
> languages, like Javascript and Python on the server and everyone go
> back to implementing in C++ (probably still too slow) or assembler. If
> you want to call out wasteful CPU cycles, running in an interpreted
> language is far, far worse than a handful of cryptographic operations.
>
> As Dave Lehn pointed out in the thread, getting consensus on a
> definition of sustainability (which we all care about), is a difficult
> thing to do. For example, if we use the traditional signature models
> we can look forward to doubling to tripling disk usage, which is a far
> more damaging/permanent thing for the environment (extraction of rare
> earth material, chip manufacturing, etc.) than a few milliseconds of
> compute. That's just ONE of the complexities that will come up in such
> a discussion; it eats away at precious WG time.
>
> This is not a zero-sum decision... there are trade-offs with each
> technology approach, and not everyone has a use case that fits into a
> neat narrative. This whole "sustainable VCs" comes off as a
> green-washing of your specification (vc-jose-cose) in an attempt to
> get the W3C Membership riled up so that they might favor a set of
> technical decisions that you want them to make. It's the same
> "blockchain guilt by association" thing that was done during the DID
> Formal Objections (and was overturned).
>
> Yes, sustainability matters and is important... but this feels like
> you're barking up the wrong tree, here (and it's just going to result
> in a big waste of time for everyone involved, and then not have a
> great deal of impact from an emissions perspective in the end).
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>