Closed jandrieu closed 5 years ago
David-Chadwick
commented
5 years ago @jandrieu Please see #294 as I have addressed your issue there. Since we can write conformance tests to check if a verifier will accept a VC or not, then the use of accept in the standard, in general, is correct.
msporny
commented
5 years ago I'll submit a PR correcting the language
@jandrieu - I agree with your train of thought, please submit a PR as that's the only way we can make progress on the issue.
@David-Chadwick - clearly the "accept" language is problematic for a number of people... but we need those people to suggest an alternative in a PR to make progress.
jandrieu
commented
5 years ago @David-Chadwick Um... I don't think we can test if a verifier accepts anything. The system has no idea what happens after a VC is in the hands of a verifier.
David-Chadwick
commented
5 years ago @jandrieu Of course we can write code that tests if a verifier's code will accept or reject a VC.
msporny
commented
5 years ago Marking this as resolved due to #298 being merged.
In the recent PR #282, in response to issue #276, the language for Terms of Use described "accepting" a VC.
This term of art, "accepting" is ill-defined, confusing, and IMO, out of scope since authorization is out of scope.
The specification should state what VCs can and cannot guarantee. That is, what "verification" means for a verifiable credential. What we should state clearly is how verification is to occur and what verification means in terms of guarantees: cryptographic math and processes for currency (aka revocation).
Any other directive that presupposes what verifiers or issuers MUST do is out of scope, especially the current language for ToUs.
Terms of Use have no computational resolution. They are only a statement of policy as expressed by the issuer. Whether or not a Verifier accepts or rejects the ToU is technically independent of whether or not the Verifier accepts the credential. One is a technical step. The other a legal one.
It is fundamentally an unsolved problem to represent ToUs such that they are programmatically and legally enforceable. The actual resolution of any ToU necessarily depends on legal interpretation: first by the issuer (and their attorneys), then by the holder (and their attorneys), then by verifier (and their attorneys), then, ultimately, by any courts involved. As much as some members of this community would like to replace the legal system with smart contracts, this type of algorithmic capture, presentation, evaluation, acceptance, and enforcement of a legal agreement is completely out of scope.
What we can say is how to verify a credential.
What we should NOT say is that the issuer has some magical ability to control what verifiers do. They do not. They cannot. That's the whole point of separating the issuer from the verifier.
Issuers can say anything they want.
Verifiers can prove that what is presented is, in fact, a statement by the issuer, to the extent of cyptographic and procedural guarantees.
What issuers cannot do, and what we should not imply or state outright, is control the use or distribution of a verifiable credential once created and given to its initial holder. They do not get to tell verifiers what they MUST do, MAY do, or CAN'T do. Issuers don't get to decide whether or not verifiers accept a given credential for any specific purpose. They just get to decide whether or not to make the claims in that credential in a verifiable way. Once they do, the use of that credential is no longer their business. Period. Full stop.
To suggest that verifiable credentials somehow magically give issuers the ability to control whether or not verifiers accept or reject a VCs is a misstatement at best, an intentionally misleading hyperbole at worst, and will absolutely lead to false expectations, bad implementations, and issuers participating in systems that are fundamentally broken because VCs don't have that particular magic.
At the moment, there are 16 places where "accept" shows up in the specification. Several of these should be removed in favor of language that more clearly states the guarantees of verifiable credentials rather than claiming capabilities that VCs do not address, do not attempt to address, and are known to be out of scope.
I'll submit a PR correcting the language, but I'd like to get input from @David-Chadwick @msporny @stonematt @burnburn and @ChristopherA @brentzundel because, frankly, I thought we had some consensus about VCs and authorization, but clearly there remain some disagreements.