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> wrote:

> On Wed, Dec 14, 2022 at 6:37 PM Michael Herman (Trusted Digital Web) <
> 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
>
>>