Re: Facing Architectural Challenges in VC 2.0

I have three qualities to offer to this thread:

I help out as co-chair for the DIF Interoperability Working Group.

I have personal experience working with LoRa and Edge Devices over the
course of several years.

I spent an active year in the mm-ADT slack (http://www.mm-adt.org/) and was
exposed to a great deal of abstract mathematics. Ryan, the resident
mathematician, is willing to hear thoughts about this area.

-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me


On Thu, Dec 15, 2022 at 4:41 AM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> 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
>
>
>
>
>
>
>
>
>
> *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> 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
>
>