4.7 Proofs

[nadalin]

Suggest that this section be marked at risk if there is no interoperable proof mechanism since JSON-LD Signature is not a complete specification, would also suggest the removal of JSON-LD from the specification since this is not in a standards body

[brentzundel]

We are limited by our charter to specifying a data model. Specifying a particular proof mechanism is a protocol decision and therefore, unfortunately, out of scope, regardless of how beneficial that would be for interoperability.
The goal of the working group in specifying the data model was to make it as inclusive of different proof mechanisms as we felt it was possible to be.

[brentzundel]

@nadalin, this issue raised two suggestions:

1. "Suggest that this section be marked at risk if there is no interoperable proof mechanism since JSON-LD Signature is not a complete specification"
2. "suggest the removal of JSON-LD from the specification since this is not in a standards body"

These have been responded to:

1. "We are limited by our charter to specifying a data model. Specifying a particular proof mechanism is a protocol decision and therefore, unfortunately, out of scope, regardless of how beneficial that would be for interoperability."
2. "The goal of the working group in specifying the data model was to make it as inclusive of different proof mechanisms as we felt it was possible to be."

If there are any further points you would like to raise concerning this issue, please let us know.

I recommend discussing the second suggestion as a working group to determine if a PR should be raised.

The first suggestion recommends specifying protocol, which is out of scope for our working group.

[nadalin]

@brentzundel You can't specify proofing w/o specifying a mechanism for interop, not how the W3C works. If you are fine with this being non-normative and not required that is fine but then you will never have verifiable claims/credentials which seems to be the goal here.

[msporny]

@nadalin wrote:

would also suggest the removal of JSON-LD from the specification since this is not in a standards body

If by "this", you mean JSON-LD, then you are mistaken as JSON-LD is a W3C Recommendation -- https://www.w3.org/TR/json-ld/ -- with a currently active W3C Working Group -- https://www.w3.org/2018/json-ld-wg/

[msporny]

You can't specify proofing w/o specifying a mechanism for interop, not how the W3C works.

It is perfectly reasonable to specify, in a data model specification, a data field whose purpose is to contain extensible proof mechanisms. The Verifiable Credentials Data Model specification has been designed by the Working Group to be proof mechanism agnostic and this is one of the mechanisms that was settled on by the Working Group.

With respect to whether this mechanisms works in practice, there have been implementations since 2011 that demonstrate (via working code) that this mechanism works with a variety of different cryptographic systems. One such implementation, which our organization uses is: https://github.com/digitalbazaar/jsonld-signatures

In any case, the WG has asserted multiple times that it's charter limits it to data model and not protocol and the test suite reflects that. The normative tests in the test suite are performed on the data model fields. There will be optional tests that test the interop on the cryptography, but again, the WG is not requiring those as they go outside of the data model and thus, our charter.

[nadalin]

@mspory There are no mechanisms defined in the specification that would allow interop, if there is no test suite then this has to be non-normative

[David-Chadwick]

this issue should be closed since it covers the same issue as #498

[stonematt]

VCWG Teleconference Resolution: https://www.w3.org/2019/04/09-vcwg-minutes.html#resolution07

RESOLUTION: The VCWG does not support the removal of JSON-LD from the specification. For Section 4.7: Proofs, interoperability is defined as at least two implementations implementing the normative statements in the section. Specifically, that the data model specifies a mechanism to express an embedded proof and the type of proof. The VCWG does not believe that it is appropriate to make this section non-normative. Issue #496 should be closed with no change to the
... specification.

Plan to close in 7 days.

[nadalin]

@stonematt Disagree as someone reading specification needs to be able to implement a proof mechanism that is fully described as a normative reference in the VC specification so that interop can be achieved. So disagree with closing

[burnburn]

The outstanding request by @nadalin to mandate support by all implementations of the JWT format will be tracked by issue #634.

The outstanding concern by @nadalin regarding JSON-LD will be tracked by issue #633. Closing.