Replaced language about requirements for "accepting" a verifiable credential

[jandrieu]

This addresses issue #293.

I attempted to retain the clarifications about the goals of ToUs and the recipient's liability should they choose to ignore those terms. However in mentioning that liability, I pointed out the legal limits of assuming how and to whom such liability accrues. Perhaps we should excise that completely, but it was the best way I could find to describe the possible means of enforcement of a ToU, given there is no technical enforcement supported by VCs.

To wit, the previous language asserted the verifier would be responsible if a holder violated the terms of use under which a credential is issued. However, the verifier receives the information covered by the ToU before they are able to review, much less agree to, the asserted terms. (There is no protocol to enforce that VCs are only given to those who have agreed to such ToUs). In such a case, I don't believe the ToU will be found legally binding on the verifier. I did add a note about seeking reliable counsel, but maybe the whole section should just be removed.

I also attempted to couch the language about "accepting" in the subject != holder discussions such that the original intention remains. The actual examples do not, IMO, address the use cases, but they work as illustrations that "may" be appropriate for some use cases. I initially started rewriting these to address my concerns, but that quickly got way too complicated to do properly in the timeframe we have.

FWIW, I'd start with having the original holder create a new credential with claims that explicitly say the new holder has been given the original credential for a specific purpose rather than including the original claims and implying the delegation without formally stating it. This gets into territory where VCs are decidedly challenging around the edge cases. In general, I am not a fan of quirky, non-explicit semantics of these use cases. If the thing is delegated, say it in claims rather than overload the semantics of the credentials themselves, which is simply that the issuer made an utterance.

Similarly, I tried to shift the parent/child examples to be clear that the assertions of relationship are information for consideration when deciding whether or not to rely on a VC. I believe this retains the intention without implying that all verifiers MUST accept the DMV's assertion of a relationship as a means of appropriate delegation for their particular use. I think it also avoids the ambiguity between "verify" and "accept". Whether or not the DMV's assertion is suitable for the delegation is subject to the business rules of the verifier. For some cases, parentage doesn't imply any rights to delegation. For instance, money stored in a trust is often completely out of reach of the parent, even if the DMV is accepted as authoritative for the relationship asserted. As such, it's inappropriate to assert that a given arrangement of multiple credentials MUST be accepted by any given verifier for any given use.

I, for one, would not view the DMV as an authoritative source for a parenting relationship (nor for weight, height, or even current address). I attempted to frame these from the perspective that verifiers reliance on any VC needs to take into account several factors beyond verification, which is what I believe @David-Chadwick's means by "accept".

Anyway, I hope this fits the bill. I made a sincere effort to meet the use cases @David-Chadwick wants addressed while fixing my concerns about untestable conformance and dependence on solving demonstrably unsolved, out-of-scope problems.

Comments and suggestions welcome.

---

Preview | Diff

[David-Chadwick]

@jandrieu Overall these changes are very good and keep with the spirit of the original objectives.
I have only made a few minor suggestions for changes

[jandrieu]

Ok. I've incorporated @David-Chadwick's suggestions.

How does this look?

[msporny]

There are merge conflicts preventing a merge of this branch, please fix them.

[msporny]

@jandrieu, I heard you say that both you and @David-Chadwick agree on this PR, which is great. I also saw a few requests to change text that you didn't respond to from @David-Chadwick ... so, I just want to make sure there is agreement to pull in this PR before I do it. Also, merge conflicts need to be fixed.

[jandrieu]

LOL. There weren't conflict before you merged those other PRs. I'll get a fix in ASAP.

FWIW, I responded to all of David's comments in the latest edit to the PR, but can't speak to whether or not he or Matt feel their comments are addressed. David at least approved the PR.

[msporny]

LOL. There weren't conflict before you merged those other PRs. I'll get a fix in ASAP.

The end is near... the axe is dropping... contributors are bound to lose some fingers. THIS IS W3C! :)

[David-Chadwick]

My last two proposed edits do not appear to have been inserted yet

[jandrieu]

@David-Chadwick, unfortunately, your two remaining suggestions don't fit with the intention of this PR.

[David-Chadwick]

@jandrieu . I understand your intention, and we both agree that a verifier can do anything it wants to with any VC that it receives, legal or otherwise. I think we also both agree that deterministic automatic tests can be built for the issues that we are discussing (if not then they are out of scope of the current discussion and therefore we should agree).
The point of contention is whether a verifier is standards conformant or not by accepting a VC that clearly states that it is not valid (according to the issuer's properties inserted into the VC) in terms of the time, place and way that it is presented. (Examples include time of issuance, expiry time, Subject only ToU).
I think your position is that the verifier is standards conformant in accepting these VCs, though may not be legally conformant.
My position is that the verifier is not standards conformant, and legality does not come into the discussion (since we are writing a technical standard).

[jandrieu]

Actually, I don't believe we can test the behavior of the verifier, which is independent of the verifiability of the credential.

My contention is that the action of the verifier is outside conformance. We don't test conformance of the verifier, we test the conformance of the software.

[David-Chadwick]

We both agree that what we are testing is the verifier's software. We can test that the verifier's software will do the following (at least)

• reject a VC with a faulty proof
• reject a VC that has expired
• reject a VC that has been revoked
• reject a VC presented by a holder NE subject with a ToU of Subject Only
  .... there are lots more, as the test suite shows

[dlongley]

@David-Chadwick,

I don't want to further complicate things, but, JFYI, we need to be careful with language like:

reject a VC that has expired
reject a VC that has been revoked

As, for example, a historical verification check should still pass under the right circumstances even though a VC has since expired or been revoked. So any language used should take this sort of thing into consideration.

[jandrieu]

I think we still have language issues about accept/reject. To me, whether or not a verifier accepts or rejects a VC is a much bigger issue than the addition of the ToU. It includes whether or not the issuer is known and respected for the claims asserted. It includes the legal evaluation of liability associated with relying on a given verifiable credential, from any and all sources. For example, whether or not the ABC (in California, the Alcoholic Beverage Control who manages adherence to liquor licenses) recognizes the VC in question as legitimate diligence for a VC who is an alcohol vendor. Such a determination requires evaluating which jurisdiction applies, which may be dependent on the current location of the individual--or perhaps on the shipping address. These downstream considerations are out of scope.

What the spec should deal with, IMO, is whether or not a verifiable credential or presentation can be "verified".

Verification, IMO, cannot depend on the verifier (and its acceptance of a given ToU) nor on the holder (and whatever identity assurance may or may not be applied).

A verifiable credential is verifiable entirely on the proof and the revocation check. Nothing more, nothing less.

To @dlongley's point, it's perfectly viable for a VC to pass verification and be expired. That will likely affect what the verifier does with the VC, but if the proof is good and the revocation check passes, then the VC is "verified". Full stop.

Downstream, what the verifier does with a VC (accept/reject) is their business and not part of verification.

[David-Chadwick]

The issuer issues a VC with or without constraints. In the former case we have no disagreements. The VC can be used by anyone for anything. In the latter case the issuer is stating when the VC is valid and when it is not. It is the issuer's right to do this. There are an almost infinite number of constraints that could be placed on a VC by an issuer, but we are only standardising the most commonly useful ones, and we have an extension point (the ToU) to allow the issuer to add non-standardised constraints in a standard conforming way. Some of the constraints can be easy to test in code, others cannot be. Most of @jandrieu's discussion concerns the latter. I am more concerned with the former than the latter (and I mostly agree with @jandrieu discussion of the latter, that they are legal rather than implementation issues). So lets close that discussion now please.

Lets concentrate on constraints inserted by the issuer that can be tested for in code. This is important because the issuer is stating when the VC is valid. I am not sure that @jandrieu agrees on this point. So here is a direct question to @jandrieu. Do you believe that an issuer can place constraints on a VC to say when the VC is valid and when it is not?

Next question. If the answer is Yes, then should a verifier's code respect this, or ignore it?

[jandrieu]

@David-Chadwick wrote:

So here is a direct question to @jandrieu. Do you believe that an issuer can place constraints on a VC to say when the VC is valid and when it is not?

An issuer can say anything they like, so they can state any constraints they desire, whether in the ToU or in the claims payload directly.

However, whether or not a claim or a credential or presentation is "valid", whether it should be "accepted" or "rejected" is dependent on more factors than are contained in the data-model and therefore are outside the scope of the specification.

The specification should say what it means to verify a verifiable credential and a verifiable presentation.

Full stop.

Anything beyond verification is, IMO, at best a non-normative illustration of what one might do with given credentials in a given use case, and those illustrations may or may not apply to any particular use of the technology. At worst, it will confuse and mislead people into believing VCs and VPs are capable of things they aren't.

[David-Chadwick]

@jandrieu. There is a flaw in your logic "However, whether or not a claim or a credential or presentation is "valid", ... is dependent on more factors than are contained in the data-model and therefore are outside the scope of the specification." This is not quite correct.

If an issuer says a VC is invalid, then no-one and nothing outside of the data model can make it valid. However, if an issuer says a VC is valid, then a verifier can still treat it as invalid using factors that are inside or outside the data model.

Since I am dealing with the former case of when the issuer says a VC is invalid, then the verification stage should cover this.

[dlongley]

@David-Chadwick,

If an issuer says a VC is invalid, then no-one and nothing outside of the data model can make it valid. However, if an issuer says a VC is valid, then a verifier can still treat it as invalid using factors that are inside or outside the data model.

A VC is a tool that an issuer uses to assert that something is true. They are able to say that they only know something is true for a little while (expiration date) and they can say that what they said previously was true actually isn't (revocation).

I don't know what it means for them to say that what they said isn't true if the person presenting the information isn't the one the information is about. That seems to defy logic and is out of bounds for a mere assertion of truth. So I don't think the analogies to those things you've presented are working for me here.

Rather, ToU is getting into expressing acceptance policy rather than whether or not what was said is true. It's essentially the issuer saying that they won't stand behind what they said if, for instance, the holder is not the subject; it is about liability. I do think that's fundamentally different from everything else we've expressed so far and that this is at the heart of what @jandrieu is arguing.

Perhaps the common ground to be reached is not to say that the VC is "invalid" when the ToU are not complied with, but rather to say that the issuer has no liability in its use -- and this can be said in prose? I don't think there's anything we can enforce at a data model level here.

[jandrieu]

@David-Chadwick To your earlier point about "valid" in the rest of the spec, I would argue any use of "valid" in a normative section is a mistake.

I don't have a problem with non-normative, illustrative sections explaining a particular approach to establishing whether or not a given VC is appropriate for a specific use by a specific verifier, as long as it is labelled as such.

As we see in issue #303, there remain areas where the text of the specification may be incorrect. This is inevitable when we have so many collaborators reviewing and proposing changes in multiple sections of the document at the same time. It will take time to tease out what makes sense and that is the conversation we're having now.

Issuers have the ability, in the current data-model, to revoke a VC. That may mean it is invalid for a particular use. Or, in fact, it may be its revoked status that makes it relevant to the verifier (who may be investigating a denial-of-service hack that seems to be revoking everyone's credentials).

What they don't have the ability to do is to require holders or verifiers to do any particular action, including agreeing to legal terms, deleting the VC, or "rejecting" a VC. They can state the terms under which they issued a credential, but after that, revocation is the only mechanism for dynamically changing the verification status of a credential.

IMO, our job is to clarify, in the spec, exactly what the data-model directly provides. Secondarily, it's nice to explain how the technology can be used beyond what the data-model provides. Protocol, identity assurance, ToU compliance, etc., are all outside the data-model.

[David-Chadwick]

@dlongley The issuer says "this is a ticket to concert A that was sold to X and can only be used by X on Date Y". This is a statement of several facts that are true. If the ticket is presented to concert B it is invalid, if it is presented to concert A on Date Z it is invalid, and if it is presented to concert A on Date Y by W it is invalid. However the statement remains true all the time i.e. it is authentic regardless of when or where it was presented. So we are not talking about authenticity, we are talking about validity.

You appear to be equating truth to validity, whereas I am equating truth to authenticity. So perhaps we should not talk about truth, due to its ambiguity, but rather about authenticity and validity. A statement can be authentic and valid, authentic and invalid, and unauthentic and invalid. It cannot realistically be unauthentic and valid, as this is a believed lie.

The point we are debating is the status of an authentic and invalid VC, which is determined purely by the data model. This is no more a ToU issue than the expiry time. (By this I mean that we could encode the validity time as a ToU, and we could encode SubjectOnly as a simple property like expirationDate).

[David-Chadwick]

To try to summarise our discussions about authenticity and validity I have drawn the following 2x2 matrix for the case where a VC is proved to be authentic to the satisfaction of the verifier, but the issuer has used the data model to indicate when the VC is valid and when it is invalid

                        Verifier determines
                       Valid        Invalid
                   ------------------------
Issuer Says  Valid |  OK        |   OK    |
in DM              |---------------------
           Invalid | Impossible |    OK   |
                   ----------------------

In the BLH corner, because the verifier's software has no choice in determining the outcome of the validation process, I am saying that the DM document should state categorically that this type of VC MUST not be accepted/used/trusted/validated by the verifier's DM conformant software.

Consequently I would expect our test suite to have tests to validate the processing of this type of VC.

[jandrieu]

"Validity" is out of scope.

"Verified" is in scope.

These are not "Validatable Credentials"

They are "Verifiable Credentials".

The specification says how you verify a verifiable credential.

It's up to the relying party to decide if any given credential--verified or not--is valid for their particular use case.

The DM doesn't say its valid. It says whether or not it is verified. The matrix above doesn't apply.

Further, the only way the issuer can say something is no longer verifiable is revocation. There is no way, within the data-model, for an issuer to say that a VC is not verifiable because of the a particular ToU, because of a particular Holder, or because of a particular Verifier. The issuer either makes a credential (with a good proof) or they don't. They can then either revoke that credential or they don't.

They don't get to decide what happens with that credential after the fact--EXCEPT for revocation triggering a subsequent verification failure.

Clearly we're spinning our wheels here. You want the spec to define what is "valid". I, and others, have said validity--the full means by which a receiving party decides whether to accept or reject a credential for their particualr use--is out of scope.

"Verification" is what we need to define rigorously.

Anything about validity is non-normative illustration, at best.

[msporny]

we're spinning our wheels here.

Yes, and I've watched as the discussion has become less and less productive.

I agree with much of what @jandrieu has said. I do see some of the points that @David-Chadwick is making, but the arguments seem tenuous and I still see a pretty sizeable disconnect in world views.

It also seems like the terminology that is being used is problematic. We need to get beyond talking about "verification" and "validation" (as people get those two confused quite often... and they are close enough that you can make an argument for either and be kinda-sorta right because of the semantic ambiguity of the words themselves... which is what I think is causing a lot of the wheel spinning).

I'm wondering if we should instead talk about "verification" and "use". Much of what @jandrieu is talking about (and what I and several others believe) is that this spec is about verification -- "Did the issuer say it and can you prove that?". Much of what @David-Chadwick has been pushing for is more about "use" -- now that you've verified the data, are you going to use it? Terms of Use is all about use... the only thing you need to verify is that the issuer said it.

VCs go through several stages:

1. Issuing
2. Holding
3. Verifying
4. Usage

... and I believe much of what @David-Chadwick is getting push back on is the final item above, which is IMHO out of scope.

[TallTed]

Most of this thread is simply and entirely out of scope.

Compliance with a data model simply means using the data model.

It has no connection to what is done with the data that is expressed in that model.

The model should make any intended protocols possible, but the model cannot make any assertions, demands, requirements about what those protocols might be, do, say, etc.

See the Provenance Data Model and the Exit Criteria used by that WG for a successful example.

[jandrieu]

@msporny I like the focus on "verification" and "use", especially because @David-Chadwick wont be the last person to want to use VCs as he does. Lots of people are going to be confused with some of the current language and it would probably serve us well to have David's issues well documented as approaches for how one might use VCs (in a way that retains clarity about what verification means).

[David-Chadwick]

@msporny If we use the IEEE definition of verification "The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process." then this agrees with your 4 stages and we should not use the term validation in our specification (which is defined by IEEE as "The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers". This is often what @jandrieu talks about.)

An example of an "imposed condition" from the IEEE definition would be a constraint on a VC imposed by the issuer, in conformance to our specification. Discussions above have indicated that only constraints that are independent of usage should be considered during verification. Thus compliance with usage-independent constraints is part of the verification process. Thus the validity time of a VC (issuance date and expiration date) are imposed constraints on a VC, are independent of its use, and are thus part of the verification process. So is a 'subject only' constraint. As I noted above we can simply encode this as

"subjectOnly": "True",

and removes it from the ToU definition and discussion, as it is independent of the use. The definition of this property could be:
"The subjectOnly property states that the verifiable credential can only be encapsulated into a verifiable presentation created by the subject."

@TallTed. I believe the above agrees with your statement "Compliance with a data model simply means using the data model."

@jandrieu "It's up to the relying party to decide if any given credential--verified or not--is valid for their particular use case."
I have a problem with the above statement, particularly a VC that has not been verified. I find it difficult to imagine any use case in which an unverified VC is useful, and I would think this is outside the scope of a verifiable credential specification. Please note that the 2x2 matrix I drew has NOTHING to do with usage, and according to the IEEE definitions, is part of the verification process. The bottom left hand square of the this matrix is saying that in NO use cases can such a VC be verified.

[David-Chadwick]

Below are a set of suggestions to move forward with this issue.

1. Try to remove the term valid from our specification (e.g. as in issuance Date)
2. Introduce the IEEE definition for verification and say that our specification is constrained to verifying VCs independent of their usage
3. Remove Subject Only ToU and replace with Subject Only property
4. Ensure we have text to indicate that enforcing usage is outside of the scope and is a legal as well as technical issue (@jandrieu's text does a good job of this already).

[msporny]

@David-Chadwick wrote:

Try to remove the term valid from our specification (e.g. as in issuance Date)

+1, fine to reword.

Introduce the IEEE definition for verification and say that our specification is constrained to verifying VCs independent of their usage

+1, we should reference the spec where this is defined.

Remove Subject Only ToU and replace with Subject Only property

+1 to remove Subject Only ToU, but I'd go further and remove "Subject Only" entirely. Digital Bazaar doesn't plan to implement that feature and I don't expect the other implementers to do so (and if they do so, most likely in their own way. Yes, this creates interop problems, but I know of no PoC/Pilot/production system that tries to express "Subject Only" as a ToU or as a property. It's typically part of the "do I want to use this credential" decision process that the verifier applies /after/ the verification process.

Ensure we have text to indicate that enforcing usage is outside of the scope and is a legal as well as technical issue (@jandrieu's text does a good job of this already).

+1 to this.

So, looks like we have a path forward for all of the items except for maybe Subject Only, which shouldn't hold up this PR (and should be done in a separate PR).

[David-Chadwick]

In #337 I have updated our definition of verification to comply with the IEEE definition, and also added the validation definition, along with a Note to say that the spec is concerned with verification. Then
I have found each occurrence of valid/validation and replaced with verify/ication where appropriate.

Note that I have replaced Subject Only Tou with Subject Only property in #283 since this one dealt with the Subject NE Holder text.

[msporny]

Ping @jandrieu ... is this PR ready to go? If so, need merge conflicts resolved.

[jandrieu]

Apologies, I thought I got this pushed a couple days ago.

@David-Chadwick and @burnburn is this good to go? I realize we'll need more PRs to clean up the rest of the doc for the new conformant language, but I'd like to get this merged in if possible.

[jandrieu]

@burnburn I believe @David-Chadwick signed off, although I'm having a difficult time "resolving" all the issues. I thought I had, but the status still shows David wants changes.

@David-Chadwick are we good to go?

@burnburn Can you chime in here?

[msporny]

Looks like the two most active in this thread have agreed that this is ready to merge. Merging.