Re: Summary of the votes during the last special topic call

Thanks for this summary, based on the 2 polls that indicated agreement:

I conclude the WG expects the data model to basically look the same as it
has previously,
but with some additional safety features related to JSON-LD processing that
are
not required to be used at all during issuance and verification, but which
might be used by any holder who wishes to use them.

I'd like to describe how I see this working, assuming a proposal for a
vocab in the primary context passes in the future:

Here is a JWT issued using DID ION using Microsoft libraries:
vc-jwt-1.1-example
<https://www.w3.org/2018/credentials/v1",
        "
https://beta.did.msidentity.com/v1.0/43066757-7f7e-4bfa-847f-27ce9a066532/verifiableCredential/contracts/Credivera
Inspector ID"
      ],
       ...

The second one does not resolve to a valid context, and it invites callers
to ping "msidentity.com" with some unique guid...

After applying the proposal regarding vocab, a v2 version of this would
look like:

   "vc": {
      "@context": "https://www.w3.org/2018/credentials/v2",
      ...

All the terms that are not defined in the v2 context explicitly would be
defined using the vocab as a base... but only at the time that this
operation was requested.

For a specific example:

    "credentialSubject": {
      ...
      "employeeNumber": "ABC1234"
    },

If anyone hold this credential wanted to transform it to obtain a human
readable definition for "employeeNumber", they could choose to do so and
they would obtain something like:

https://www.w3.org/ns/credentials/claims/private#employeeNumber

The specific URL above would be determined by the WG.

If in the future, IF Microsoft wanted to add support for some automatic
credential documentation feature, for all their credentials, they could add
back a second context, and they would control the term expansions using
vocab, for example:

    "vc": {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        { "@vocab":  "https://microsoft.example/help-center#employeeNumber"
}
      ],
       ...

Nobody would ever be forced to do this, and yet, the core data model we
developed at W3C CCG and published in v1 and v1.1 would be enhanced and
preserved.

Nobody would be required to do any JSON-LD processing at the time of
issuance or verification for vc-jwt, vc-jws, vp-jwe, cose signatures, etc...

In addition, we could keep the design aesthetics and resolution and
dereferencing features of the core data model, with a formal basis for them.

For example:

Using *type* to identify a Class and *id* to identify an instance that can
be resolved to a representation.

Multiple inheritance type, using camel case convention, supporting objects
and strings interchangeably,
allowing for smaller specs to extend the core data model for things like
*credentialStatus*, *credentialSchema* and *evidence*.

And to be clear, NO JSON-LD PROCESSING of any kind would be required as
part of issuance or verification, but a rich and consistent data model
would be preserved and available to users who want to use it, or are
required to support it.

Adding @vocab to the v2 base context would be an improvement to
overall experience, it would not add any bytes or burden to vc-jwt, vc-jws
or cose, and it would enable those representations to trivially meet the
requirements of verifiers who require valid, fully documented and
interoperable JSON-LD.

Regards,

OS




On Mon, Nov 28, 2022 at 11:23 PM Kristina Yasuda <
Kristina.Yasuda@microsoft.com> wrote:

> Hi,
>
>
>
> A kind reminder that we have a special topic call at 8AM PST on the
> relationship of JSON-LD and VCDM (including the usage of @context and
> @vocab).
>
>
>
> As was requested, below is *the summary of the votes for each of the poll
> run during the last week’s special topic call*:
>
>
>
> Poll: Representations of the VC 2.0 data model must be restricted to only
> JSON-LD.
>
> Outcome: No agreement (more -1s) with four +1, One 0, five -1s.
>
>
>
> Poll: It must be possible to have credentials that do not require @context
> processing.
>
> Outcome: Agreement with fourteen +1s, zero 0, zero -1. (out of which at
> least two +1s were to some definition of @context processing)
>
>
>
> Poll: It should be possible to syntactically determine when JSON-LD
> processing is required and when it must not be performed.
>
> Outcome: No agreement (more +1s) with five +1s, zero 0, four -1s. (out of
> which, two votes to clarify JSON-LD processing)
>
>
>
> Poll: Interoperability can be achieved without a graph-based data model.
>
> Outcome: No agreement (more +1s) with seven -1s, one 0, five -1s.
>
>
>
> Poll: JSON-LD algorithmic processing of @context is not required, but must
> not be broken for JSON-LD processors, either. So, you don’t have to process
> it, but you can’t include a value that blows up JSON-LD processors either.
>
> Outcome: No agreement (more -1s) with eleven +1s, one 0, three -1s. (out
> of which at least two votes asking for alternative phrasing)
>
>
>
> Poll: If a processor chooses to process @context, it may do that via
> simple string equality comparison that compares, at most, 1-2 URLs (to keep
> things simple).
>
> Outcome: No agreement (more +1s) with nine +1s, three 0s, three -1s
>
>
>
> Poll: JSON-LD is not mandatory to create or process a VC
>
> Outcome: No agreement, close to rough consensus with eleven +1s, zero 0s,
> two -1s (there was some confusion around what to vote on)
>
> Poll: One does not have to know about JSON-LD to use VCs.
>
> Outcome: No agreement, close to rough consensus with five +1s, zero 0,
> one -1.
>
>
>
> Poll: A compliant VC must not break a JSON-LD Processor.
>
> Outcome: No agreement (more +1s) with ten +1s, two 0s, three -1s.
>
>
>
> Poll: It will be illegal to fetch certain remote contexts from the Web (as
> outlined above). This will enable a usage of VCs that require no remote
> context downloading, reading, or processing (simple URL string comparisons
> can be used instead).
>
> Outcome: No agreement (more +1s) with five +1s (roughly), three 0s, four
> -1s.
>
>
>
> Poll: It will be legal to use @vocab as either a) specified in the first
> context, b) specified in the second context, or c) specified inline via
> @vocab in the second context position, or d) any variation of the previous
> options.
>
> Outcome: Agreement with fourteen +1s, three 0s, zero -1s.
>
>
>
> Best,
>
> Brent and Kristina
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>