Adds User Task for "Trust Claim"

[RieksJ]

The Motivation section in 4.1 Issue claim says "Individuals and organizations need a way to issue claims about themselves or others that can be verified and trusted". While there is a user task Verify claim, there is no such thing for trusting claims. This pull request adds text for a section that fills in this omission.

---

Preview | Diff

[stonematt]

fixes #95

[jandrieu]

This is definitely a User Task that is under served today in the document, namely, the verifier must be able to determine whether or not an issuer is credible for a given claim. We've largely treated that as out of scope, but it is an important task in the process of accepting and relying on a given VC.

However, the proposed text dives into the details of how that might be done (even proposing how it SHOULD be done), rather than focusing on the requirement of what needs to be done. The latter gives spec authors and implementers the freedom to address implementation questions separately from the requirements.

Could you re-phrase this to present the task without dependency on a particular implementation approach?

[stonematt]

@RieksJ did that last comment make sense? Will you update the PR accordingly? We'd like to have this concept included.

[RieksJ]

There is this difficulty that this task is not a technical one. Determining whom to trust is a people task. The text states that ways must exist for issuers to convey whatever verifyers may need to know in order to decide whether or not, and if so for what purposes, it might use a VC that the issuer may issue. It uses the term 'advertisement' to refer to any such way. While to me this doesnt say anything about how to or what to implement, thats not the case with Joe. I will think about how it can be rephrased

[jandrieu]

@RieksJ We discussed this a bit last Tuesday. There's agreement that this step is both important and poorly communicated in the current docs.

However, two changes were requested.

First, the step should be titled "Validate Claim", which is fairly well described in the spec (and missing from the use cases document): https://w3c.github.io/vc-data-model/#validation

In short, "verification" is verifying the authenticity and timeliness of the VC. "Validation" is making sure it meets policy requirements, aka, the human stuff, including whether or not you can "trust it".

Second, we need to express a balance between automation and human review. Some of the questions in the validation process should be vetted by humans rather than automatically applying a fixed heuristic. This becomes even more vital as machine learning and AI are used more and more as gatekeepers to services that may impact human life, liberty, or dignity. The preferred option in many situations is to escalate rather than deny.

The general notion was that we should use automation to streamline validation as much as possible, but that humans should be in the loop where appropriate.

For example, if you're relying on an automatically updated list of issuers, e.g., from a federated white list, it most likely makes sense to have a human administrator review any updated lists before applying them in the automated system, in the same way that you should manually upgrade software dependencies (and test thoroughly) rather than automatically rely on potentially adverse changes in someone else's code base. Processes which are 100% automated can provide ready attack vectors for bad actors and often lead to the tyranny of data when errors seep into the system.

There are enough cases where a human in the loop is the only humane option that the requirement for validation to be automated wouldn't be appropriate. The goal of enabling automation, subject to human review, however, is an excellent requirement.

If you could incorporate that notion into the user task, we'd love to add it to the document.

[RieksJ]

W.r.t. the first change you requested: you guys have misread my contribution, which is not about validation, but about enabeling a verifier to do validation:

• The definition of validation in the spec you refer to reads as follows: "The assurance that a verifiable credential or a verifiable presentation meets the needs of a verifier and other dependent stakeholders". Validation hence is a process that is applied to an actual credential (one that has been received from a holder).
• The task "Trust Claim" that I propose is NOT about something a verifier does to an actual credential it has received, i.e. it is NOT about validation. Rather, it makes the case for explicitly stating these needs that the definition is talking about, so as to enable a machine to ensure that a (received) VC meets them, i.e. validate a VC.

In my way of thinking, the result of a "Trust Claim" task (of some party) would be a machine readable policy that contains all information that a verifier (owned by that party) needs in order to construct a presentation request that only requests (claims from) credentials that its Owner has decided to trust. Say that Example.com trusts issuer foo.com but not issuer bar.com, both of which would issue a credential C. The "Trust Claim" task that Example.com would need to execute would then result in a machine readable policy that instructs a verifier to ask for the C credential issued by foo.com.

I don't mind changing the title to something else, as long as it is appropriate. As I think will be clear from the above, "Validate Claim" is inappropriate for what I suggested.

W.r.t. the second request, I do agree it is appropriate to have a(nother) use-case around validation that addresses automated validation, human validation, and grounds that arbitary parties can use to (subjectively) decide how to balance the two in different transactions. However, I disagree that this should be part of this pull request; it deserves one of its own.

[jandrieu]

I'm afraid neither @stonematt or I could figure out what you meant by "which is not about validation, but about enabeling a verifier to do validation:"

Given that we aren't quite understanding what you're getting at here, we're going to defer this issue, without prejudice so that future editors might consider it when revising the document further.

[RieksJ]

I am baffled. The way I read your comment is that neither of you can figure out the difference between doing something (in the case at hand: validating) and enabling one to do that something. I am sure this is not what you meant. Let us talk this over at rwot9 in Prague. Ok?

[jandrieu]

The bigger issue is that this needs to close immediately. While we may be able to tease out what you mean in Prague, this document needs to ship.

My short answer is that the user tasks are not defined at the granularity you are suggesting, so there must be a disconnect.

ALL of the user tasks are about enabling the ability to do something. That's what it means to include a use case: the spec should enable this particular usage. We don't see a difference between doing it and enabling it. We also don't see that pattern of distinction in any of the current tasks, which makes me think we have a category error between the distinctions you want and the granularity of the distinctions already framed by the use case document.

[RieksJ]

I'm fine with deferring if that's what's needed right now.