Re: Layering/Composability of Verifiable Credentials (was: Re: Market Adoption of VCs by Fortune 500s (was: Re: DHS Verifier Confidence/Assurance Level Expectation/Treatment of non-publicly defined Vocabulary/Terminology -- by using @vocab))

Christopher Allen <christophera@lifewithalacrity.com> wrote:
>  (For instance, you really need to use SPARQL if you are serious about
using JSON-LD data in a large database given an open-world model, and using
that requires you to have a deeper understanding of RDF that JSON-LD
abstracts out.)

For what it's worth, I also agreed with most of the rest of your message,
Christopher, but didn't quite feel this assumption was right. And that's
from my perspective wearing hats over time of the product owner, full stack
developer, and engineering manager on a project (Badgr) that implemented
Open Badges 2.0 import/export in JSON-LD for production with hundreds of
thousands of users. Our databases were MySQL and Mongo, and we did not have
JSON-LD specific tooling built in at the database or ORM layer. We did all
our JSON-LD processing as part of application code prior to storage in the
database. Our business logic never really tried to truly embrace the
open-worldedness of the OB data model; it stuffed extra data into a
JSONField and only used it for exports or data presentations to users, not
for any automated understanding of achievement data. This was the right
choice for that product and seems to work pretty well in a bunch of other
products I've seen in this space as well.

As it turned out, only a small number of developers on the team needed to
have much JSON-LD or RDF knowledge. I mostly carried that burden alone and
just made sure that when relevant sections of the system were modified
across a team of upwards of 50 people including over a dozen code
committers, that important functionality didn't break. Most of the
important functionality was covered by automated testing in any case. I do
agree in general that RDF concept knowledge and JSON-LD practical knowledge
is helpful to have somewhere on the team or among project advisors for
implementing VC 1.1, OB 3.0, CTDL or other JSON-LD-based specs or
vocabularies in this space.



Manu Sporny <msporny@digitalbazaar.com> wrote:
> Our focus at present is on improving the ecosystem/community tooling so
developers don't have to do as much "low-level coding" as they had to do in
the past and can focus more at the application layer...

I very much like this focus, and I'm contributing to VC (OB 3.0 flavor)
tooling that aims to serve the same purpose. This is the same pattern that
I found successful in Badgr. The JSON-LD processing for OB 2.0 was all done
in an open source package published by the 1EdTech standards body (code
<https://github.com/1EdTech/openbadges-validator-core>, hosted service
<https://openbadgesvalidator.imsglobal.org/>). Other implementers besides
us used the same package, either over HTTP API or directly as a python
module in their service to canonicalize and validate OB inputs into a
consistent format (compacted into the OB v2 context). The presence of this
tooling, I think, helped developers adopt OB 2.0 more easily. Issuer
implementers could pretty much just copy the examples from the OB 2.0 spec
<https://openbadgespec.org/> and not even really care why they were putting
a @context property in the document, as long as the validator didn't give
them any errors. Verifier-side implementers could integrate with the
validator API and also not really care much about JSON-LD other than
recognizing that there might be some additional properties in the documents
beyond those specified in the spec.

The issuer quickstart guide
<https://github.com/1EdTech/openbadges-specification/blob/4a6b1417c0311b6b8673e2c53872623b22691a55/ob_v3p0/impl/getting-started.md>
the OB community is writing for OB 3.0, which uses the VC Data Model 1.1 is
a bit more involved than for 2.0 (comments and suggestions welcome for a
couple more weeks), but issuers (90%+ of the ecosystem) still don't need to
think too much about the JSON-LD details, they just need to include the
relevant contexts and follow the JSON-schema provided by the OB 3.0 spec.
When it comes to making a proof, I hope they don't roll their own, but that
they use a library for their selected proof technique written by
cryptography experts. Key management is still a significant challenge, and
there are other technical hurdles that I hope we can make easier for
implementers by providing tooling that addresses more of the layers of the
VC/OB stack.

As of 2020, 1EdTech (formerly IMS Global) counted over 43 million issued
Open Badges
<http://content.imsglobal.org/badge-count-2020/badge-count-2020/>. Knowing
their sources, these were all in Open Badges 2.0 JSON-LD format with a
long-tail distribution across source platforms. As most of these platforms
all upgrade to OB 3.0 over the next 12 months (all the major ones have
committed to do so), these credentials and the millions more that have been
issued since 2020 will be available to recipients in Verifiable Credentials
1.1 JSON-LD format (maybe some will be JWT-flavored). A relatively small
number of individuals will need to know the deep inner workings of JSON-LD
and RDF in order to effect this transition. I'm sure there will be
technical difficulties on the way, but we're going to work collaboratively
to make this possible, and I think the next few months' worth of advances
in shared tooling could be really helpful in making this possible.



Anyway, long story short, I've been in the role of "the person who worries
about the JSON-LD/RDF stuff so that other people don't need to" in product
teams and standard groups fairly successfully over the years, and I've
advised more than a dozen companies on how to implement OB 2.0 in JSON-LD
(now I am actively advising companies on OB 3.0/VC). In that process, I
found that it is helpful when somebody I'm talking to has more than
surface-level understanding of JSON-LD, but it was absolutely possible to
do everything necessary with almost zero specific knowledge of these
concepts, if the implementer was knowledgeable about JSON.


*Nate Otto*
nate@ottonomy.net
Founder, Skybridge Skills
he/him/his