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

+1

Mike Prorock
mesur.io

On Tue, Nov 29, 2022, 08:46 Orie Steele <orie@transmute.industries> wrote:

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