RE: Facing Architectural Challenges in VC 2.0

RE: I suggest that perhaps W3C isn't the right home, because web-centrism is woven into its DNA. … I would like a technology that is usable on the Web, but also over the internet writ larger than Web (e.g., email, ssh, UDP...), plus over Bluetooth, over LoRa, over Kafka, over sneakernet, etc.

Here’s a couple diagrams I’ve been floating around …interestingly, mostly in conversations centered outside CCG …e.g. DIF DIDComm channels. There is a lot beyond the W3C Web horizon we need to consider.  I’ve been calling it Web 7.0 (see below). Reference: https://hyperonomy.com/2022/12/11/web-7-0-didcomm-agent-architecture-reference-model-didcomm-arm-0-27/  I’m throwing the idea of Web 7.0 into the mix here in CCG to help broader the conversation along the lines Daniel as suggested.

Best regards,
Michael

[cid:image001.png@01D91036.AE1C9F10]



From: Daniel Hardman <daniel.hardman@gmail.com>
Sent: Wednesday, December 14, 2022 9:30 PM
To: Christopher Allen <ChristopherA@lifewithalacrity.com>
Cc: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; Wolf McNally <wolf@wolfmcnally.com>; Shannon Appelcline <shannon.appelcline@gmail.com>; Credentials Community Group <public-credentials@w3.org>
Subject: Re: Facing Architectural Challenges in VC 2.0

ACDCs take an architectural perspective that resonates strongly to several of your points, Christopher. They provide carefully isolated layers to keep cryptographic and non-cryptographic concerns distinct. They use labeled property graphs. They replace Linked Data URLs with self-addressing identifiers (SAIDs). They solve the CBOR problem and the data canonicalization problem once and for all, across the board. They use only simple cryptography, yet provide powerful multisig and graduated disclosure. They are post-quantum ready. They avoid centralized registries. They don't make the open world assumption, but they also avoid several of the downsides of the closed world assumption. And they don't call themselves "credentials" but rather "authentic chained data containers."

This is not to advocate for ACDCs here; I'm sure downsides to their approach could be pointed out and analysed, but that's not the purpose of your thread. My point is simply that there is strong evidence that A) others share your concerns; and B) it is possible to come up with at least one coherent solution that addresses them broadly -- and efforts to do so are not in their infancy.

Early in the marathon discussion in issue #947, I attempted to push for a view of VC 2.0 scope that would allow technologies like ACDC to fit under the tent. However, I became concerned that this is tilting at windmills; it simply breaks too many assumptions that are woven deeply into the minds and hearts of those working hardest on the standard. As Joe pointed out, getting consensus in the current group for a bridge that far may be expecting too much. I also noted with frustration that the issue is continuously reframed as one of narrow misalignment around developer friction. There are those who want to refactor how @context is handled that are motivated by that concern, but simplifying the argument to that headline feels like it misses several larger points (which you've raised). So later in the thread, I suggested that we simply describe VC 2 as "VC LD" (VC for Web might be another accurate title), leave the current assumptions in place, and make it easier for developers who are willing to emit credentials as linked data to do so correctly.

To Michael's question about where/how to constructively work the issue, I suggest that perhaps W3C isn't the right home, because web-centrism is woven into its DNA. The abstract for the W3C spec says "This specification provides a mechanism to express these sorts of credentials on the Web." The status section says "W3C recommends the wide deployment of this specification as a standard for the Web." The first three paragraphs of the intro says credential use "on the Web continues to be elusive"; "Currently it is difficult to express...third-party verified machine-readable personal information on the Web"; "The difficulty of expressing digital credentials on the Web makes it challenging to receive the same benefits through the Web that physical credentials provide us in the physical world. This specification provides a standard way to express credentials on the Web."

I supposed this text could be revised to convey a broader conception, but I don't think it should be. The text as it currently stands is an accurate capture of the priorities and mindset. It is exactly what we could and should produce in an organization that takes as its motto, "leading the web to its full potential" (see w3c home page).

I would like a technology that is usable on the Web, but also over the internet writ larger than Web (e.g., email, ssh, UDP...), plus over Bluetooth, over LoRa, over Kafka, over sneakernet, etc. I've come to feel that IETF is a better home for that kind of thing. I invite you to come join the ACDC discussions there, if you're interested -- or to pull the ACDC discussions and discussions from other parties who share these concerns into an IETF home that you recommend, if that's better.

On Thu, Dec 15, 2022 at 4:02 AM Christopher Allen <ChristopherA@lifewithalacrity.com<mailto:ChristopherA@lifewithalacrity.com>> wrote:
On Wed, Dec 14, 2022 at 6:37 PM Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
Christopher, from a practical perspective, any suggestions on how to carry this discussion forward in a manageable way? For example, do you want to open a separate GitHub issue for each of the Challenges you’ve identified?  I don’t think having everyone reply to this long email is very practical.

I'm not sure. One of the problems is which community? Which repo?

I know that my post is intimidating to read, follow and respond to, but as these problems are at some level related to which community wants to address these topics?

Thus my first question is: Is there sufficient interest in this community or the VC-WG to look further into these?

The VC-WG will likely find these issues distracting, and if they narrow their goals to a JSON-LD-focused spec, that could be great — it is achievable. Then we don't distract them and we can move these discussions elsewhere.

But if there's a consensus that the VC-WG needs one data model for credentials, for JSON-LD & JWT & CBOR & other needs, then the discussions could be moved to the VC-WG. But so far, I've not seen an emerging consensus there, and trying to address these architectural issues will likely mean they will not be able to ship improvements to VC/JSON-LD at all.

However, if there is ultimately a consensus to solve these architectural issues or find some way to split the problems up, we could move the discussions appropriately. If that includes WG work, I would also encourage my non-W3C member sponsors to do so as well by becoming members of the W3C.

I have posted one issue to the VC-WG's vc-data-model, on the topic of layer violations: issue #986 https://github.com/w3c/vc-data-model/issues/986


-- Christopher Allen