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

big +1 orie - this is a very helpful summary and example

a couple of possible proposals from this (to tune or throw darts at):
1) Add @vocab to the v2 base context
2) An implementation MAY perform JSON-LD processing on a VC, but is NOT
required to do so
3) VCs must be valid JSON and contain @context pointing to at least the
base context, with no additional contexts required

Mike Prorock
CTO, Founder
https://mesur.io/



On Tue, Nov 29, 2022 at 7:58 AM Orie Steele <orie@transmute.industries>
wrote:

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