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

4.10 Presentations #488

Closed nadalin closed 5 years ago

nadalin commented 5 years ago

There seems to be no standardized presentation, so how can there actually be interoperability ? Suggest this option be at risk. There are many zero-knowledge proofs mechanisms out there in wide usage beyond the limited usage of ZKP. Suggest usage of IDEMIX and U-PROVE.

brentzundel commented 5 years ago

Determining which features to consider at risk was based on feedback from implementers. To my understanding, all of those who responded said that they would support this feature.

The specifics of what is needed for a verifiable presentation, the proof/verification mechanisms that should be used, the properties that are necessary to support those proof/verification mechanisms, are all protocol decisions. As such, they are out of scope for this group to specify.

It is because there are many zero-knowledge proof mechanisms out there in wide usage that ZKP is the term used in the data model. ZKP does not refer to a specific zero knowledge proof mechanism, but simply stands for Zero-Knowledge Proof.

If a PR were to be raised that specifies IDEMIX or U-Prove in an example of how zero-knowledge proofs may be used in a presentation, it would certainly be considered for inclusion.

nadalin commented 5 years ago

I don't understand how you will declare interoperability to exit CR unless 1 mechanism is chosen, so this is not to my undestanding a implementation issue its a interop issue where tests can be written to show 2 or more implementation can use same mechanism and interop. If there is no given default mechanism this would remain at risk

brentzundel commented 5 years ago

I may be wrong, but my understanding of the level of interoperability required for a data model specification to exit CR, is that multiple implementers can create artifacts that fit the data model.

We can only judge interoperability based on how well the credential matches the format of the data model. We can't judge interoperability based on how the credentials are used, because how the credentials are used is determined by protocol, and the working group can't specify protocol.

Is it accurate to say that your concern is that true interoperability cannot be shown without some sort of normative guidance on how the data model must be used? If so, that is a concern that many in the WG share, but it is also the reality in which we have been required to operate due to the limitations of our charter. If not, please help me to better understand your concerns.

And if @burnburn or @stonematt would like to confirm or correct my understanding about the interoperability requirements for the data model to exit CR, I would appreciate their feedback.

nadalin commented 5 years ago

The text is not marked non-normative, so my understanding is that you will have to show interop on normative parts of the specification as we had this issue with WebAuthn and extensions

brentzundel commented 5 years ago

It would be very helpful for my understanding of your concerns if you could answer my question.

Is it accurate to say that your concern is that true interoperability cannot be shown without some sort of normative guidance on how the data model must be used?

nadalin commented 5 years ago

If sections are normative then you need to prove interoperability, so for a trust model there would have to be a mechanism defined to achieve interoperability. otherwise the specification may or may not be interoperable

brentzundel commented 5 years ago

Do you feel that interoperability needs to be shown beyond two separate implementations that both adhere to the normative statements made in the specification?

msporny commented 5 years ago

There seems to be no standardized presentation, so how can there actually be interoperability?

Some of the text in this section could be improved as the normative requirements are there, but a bit nebulous as the section is constructed in a way that's different from the other sections. We can do a few non-substantive changes to clarify the normative requirements in the section that the group has agreed to. I'll submit a PR for that if someone else doesn't beat me to it.

msporny commented 5 years ago

Suggest this option be at risk.

As @brentzundel mentioned, we collected "intent to implement" information from implementers and there were many more than two independent responses that stated that they would implement this feature. Thus, it was decided to not mark this feature as at risk.

nadalin commented 5 years ago

@msporny Sorry but unless there are documented mechanisms in this specification this would still be at risk for interoperability reasons

msporny commented 5 years ago

PR #538 has been merged to partially address this issue. Other language clarifications will be made in a subsequent PR.

msporny commented 5 years ago

@nadalin wrote:

Sorry but unless there are documented mechanisms in this specification this would still be at risk for interoperability reasons

The WG has been discussing your assertion over the past two weeks. It is resulting in multiple clarifications to the specification. Will note those PRs once they're in in this issue.

msporny commented 5 years ago

PR #531 has been merged to partially address this issue.

msporny commented 5 years ago

PR #535 has been merged to partially address this issue.

stonematt commented 5 years ago

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

RESOLUTION: Implementers were polled before the specification entered the Candidate Recommendation phase and more than two implementers stated that they would implement this feature, thus it is not at risk. Interoperability for this feature is achieved if at least two independent implementations support the data model features in the specification, The WG acknowledges that there are several different types of zero-knowledge proof mechanisms and has provided a mechanism where one or more of those mechanisms can be combined with the data model in the specification. The group agrees that non-substantive changes should be made to the section to clarify the normative requirements more precisely and then issue #488 should be closed after that PR is approved and merged.

PR is merged, waiting on other PR.

msporny commented 5 years ago

PR #547 is waiting to be merged to close out the rest of this issue.

nadalin commented 5 years ago

@stonematt This would still be at risk if the someone that is reading the specification can't implement a standard way to do a Presentation, having proprietary way to do presentations is defeating the purpose of the standard. So I don't agree with closing this

burnburn commented 5 years ago

The outstanding concern by @nadalin regarding interoperability will be tracked by issue #632. Closing.