search

w3c / vc-data-model

W3C Verifiable Credentials v2.0 Specification
https://w3c.github.io/vc-data-model/
Other
287 stars 105 forks source link

Section 5 normative and non-normative parts #524

Closed nadalin closed 5 years ago

nadalin commented 5 years ago

I see that section 5.3 Extensibility is normative but I don't see how this can be normative, I can accept that this is informative and thus non-normative. What did I miss?

Section 5.5 Refreshing is normative but I don't see a mechanism provided in detail that would prove interop, if no mechanism is provided then this should be marked non-normative. There has to be a mechanism provided to show interop, it can't just be that someone has implemented something.

Section 5.6 Terms of use same as section 5.5

Section 5.7 Evidence same as section 5.5

Section 5.8 Zero Knowledge Proofs same as section 5.5

Section 5.9 Disputes same as section 5.5

David-Chadwick commented 5 years ago

The interop and normative part concerns the MUST statement in each of the above. Is this any different to X.509 mandating that each extension must have its own OID?

nadalin commented 5 years ago

@David-Chadwick yes, as you can point ITU OID specification, I have no idea what mechanisms to use to achieve interop here unless something is specified

David-Chadwick commented 5 years ago

The type and/or id are specified. These are the fields that guarantee interop. the verifier reads the type and if its knows the type, it can interpret all the other properties, but if it does not recognise the type, then it can not understand the properties. If we had been allowed to specify protocol then we would have said whether the verifier must either reject the VC or ignore the top level property for those types it does not understand. But since we were not allowed to mention protocol, we could not say this. Nevertheless we can still mandate that the types and/or ids are mandatory in the data model. And this can be tested for in terms of conformance to the data model.

nadalin commented 5 years ago

@David-Chadwick Specifying ID and Type are great but how do you get interop on the refresh service? I choose 1 refresh service and get one result and then select a different refresh service I get a different result so are you saying the interop is just being able to call the refresh service and what happens is undetermined ?

David-Chadwick commented 5 years ago

@nadalin I would suggest that interop on the refresh service is a protocol issue and it is out of scope of the current CR. So I am saying that even calling the refresh service is out of scope. Conformance is simply to the properties in the data model.

nadalin commented 5 years ago

@David-Chadwick Then I would say this is non-normative as you can't get interoperability

David-Chadwick commented 5 years ago

@nadalin Can I leave it to the writers of our conformance test suite to answer you definitively on this one please. They will know if these data model properties can be tested for or not, for example, if my code produces a VC and their testing code validates its conformance to the spec.

nadalin commented 5 years ago

@David-Chadwick There will have to be a set of interoperability tests, these need to satisfy the W3C that there is interop. I just went through all this with WebAuthn and what needed to be tested and what makes things interoperable, things I see here would not meet that bar.

msporny commented 5 years ago

@nadalin wrote:

I see that section 5.3 Extensibility is normative but I don't see how this can be normative, I can accept that this is informative and thus non-normative. What did I miss?

Yes, Section 5.3 should be non-normative as it doesn't contain any normative statements. Section 5.3.1 should remain normative as it contains normative statements.

msporny commented 5 years ago

Can I leave it to the writers of our conformance test suite to answer you definitively on this one please. They will know if these data model properties can be tested for or not, for example, if my code produces a VC and their testing code validates its conformance to the spec.

Yes, this is exactly how the conformance test suite is written. We test for the existence of the values, not the actual values themselves as those would be extensions, which our charter does not allow us to work on.

msporny commented 5 years ago

@nadalin wrote:

Refreshing is normative but I don't see a mechanism provided in detail that would prove interop, if no mechanism is provided then this should be marked non-normative. There has to be a mechanism provided to show interop, it can't just be that someone has implemented something.

The interop that the WG is seeking is at the extensibility points, not the extensions themselves. The WG had a long discussion about this and agreed that this was the proper way to proceed. A conformance test suite exists and the group has already ensured that all conformance tests in the specification are testable. We will check with the WG as to whether this is still the current consensus position of the group.

nadalin commented 5 years ago

@msporny that will not work, the actual mechanism will have to be defined. It's like a intention framework, you have to show interop on the actual extentions not the framework

stonematt commented 5 years ago

Resolved on VCWG call 4/16/2019. RESOLVED: The VCWG seeks to demonstrate interoperability at the data model and extension points in the specification, not the extensions themselves as the group is not chartered to work on extensions. The VCWG has reviewed all conformance statements, has implemented a test suite that tests all required conformance statements in the specification, and asserts that this approach is appropriate for a data model specification. Section 5.3 should remain normative as ... it contains a normative section 5.3.1. Section 5.3.1 should remain normative. Other PRs are in process that clarify the findings of this proposal and once they are made, issue #524 should be closed.

nadalin commented 5 years ago

@stonematt Extension frameworks can be normative but any extension points will have to show proper interoperability of any mechanisms or these would be at risk and would ne non-normative. So don't agree with closure

nadalin commented 5 years ago

@stonematt I also don't see anything in charter that says that extension points can't be worked upon, if there are protocols already defined then no issues, I agree if you are inventing a new protocol that is called out in charter as out of scope

msporny commented 5 years ago

PR #591 clarifies the intent of the spec to define extension points but not concrete implementations. This issue should be closed once it's merged.