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

I was planning to run something similar:

PROPOSAL: The v2 `@context` will contain an `@vocab` with a base IRI that
the working group chooses.
PROPOSAL: The base IRI will be a URN.
PROPOSAL: The base IRI will be a URL.

OS

On Tue, Nov 29, 2022 at 9:43 AM Mike Prorock <mprorock@mesur.io> wrote:

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

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

<https://www.transmute.industries>