Add task 'Check revocation' and use-case that demonstrates its use/need

[RieksJ]

The VC Use-cases document talks about the ability of issuers to revoke credentials that they issued, but it does not mention who should be able to check whether or not credentials are revoked. Here is a suggestion to fill in that gap

4.8 Check revocation

Requirement: at the point in time that the inspector decides whether or not to provide a holder with the product or service that the holder requested, the inspector must be able to determine for every credential that the holder has provided, whether or not the credential has been revoked by its issuer.
Motivation: A considerable time may have elapsed between the holder applying for a product or service and providing credentials for that, and the inspector deciding whether to honour or reject the application. If the inspector can only rely on non-revocation proofs that were valid at the time the holder provided its credentials, the probability that any of them is revoked increases as time goes by. Consequently, the inspector's risk of making its decision with invalid (revoked) credentials increases in a similar fashion.. So, the inspector needs the ability to check for revocation at any point in time, which it can also do for checking the digital signature or the credential's non-expiration. Furthermore, this ability will allow the inspector to re-evaluate this decision on a regular basis, which is beneficial when provisioning continuous services (e.g. a parking permit for the disabled - see the use-case)
Needs: (t.b.d.)

Here is a use-case

X.Y Parking Permit

The city of Groningen issues at most one parking permit to any family whose members live at the same city address. Also, a parking permit is only issued if the applicant owns or leases the vehicle. In order to automatically issue and enforce the parking permit, the city of Groningen requests every applicant to provide two credentials: one that is issued by the municipality itself that states that the applicant resides at some address in the city, and another one that is issued by the car registration agency of the Netherlands that states the licence plate of the vehicle that the applicant owns or leases. Several months after Michiel has successfully applied for a parking permit in Groningen, he decides to sell his car, which implies a de-registration of him as owner, and the ownership credential to be revoked. When the city checks its parking permits (e.g. every week/month/year), it will detect that Michiel is no longer eligable for a parking permit, which it can subsequently revoke. Note that if Michiel did not decide to sell the car (and supposing that the credentials have not expired), he would not need to re-apply for such a permit every year, which saves on agony.

[TallTed]

Without addressing the rest of this, please note that "inspector" is a deprecated term; these should all be changed to "verifier".

[stonematt]

We like this use case in general. We have a similar focal use case that addresses the need for a verifier to reason over both a "collection of credentials" and the need for a verifier to "confirm validity of a credential later" for ongoing business purposes. These concepts are covered in the Expert Diver Focal use case in pr #100

We propose closing this example and relying on the focal use case that's currently in flight.

[stonematt]

from PR #10
good catch. This process should be part of the Verify Claim task, rather than it's own task. A revocation and status check is part of the verification process, as stated in the Datamodel in section 5.1:

A verifier verifies the authenticity of the presented verifiable presentation and verifiable credentials. This should include checking the credential status for revocation of the verifiable credentials.
Rather than make a new user task, let's update section 4.3 of the Use Cases.

Recommend: Reject this PR and make a new PR for Verify Claim.

[RieksJ]

@stonematt: While it's ok to have this process be part of the Verify Claim task, it should also be a task of its own. The reason is that part checking of verification properties has two components: one part is doing checks of which the outcome does not change over time, such as checking the signature. The other part consists of checks that may change in the course of time. That includes checking for expiration and revocation. These must be considered different tasks, because while the first can be executed at any time in the verification process (note that processes are not tasks), the second should be executed immediately before the (verified) data is used so as to prevent invalid data being used (e.g. to make decisions).

[jandrieu]

@RieksJ There are a couple of challenges with incorporating your suggestions. The biggest is that the working group ends in a matter of weeks, so at this stage we simply can't entertain significant shifts, no matter how meritorious.

The second however, is that there really is no separation between the two tasks. The keys might also be revoked or rotated at any time, rendering the credential invalid, even separately from the status check.

The root problem is one of caching, which ultimately becomes a matter of policy, driven by the risks of reliance and economics of the check. In theory, you should check the credential--including its signature and the status of the claims--EVERY time you rely on it. In practice, this isn't practical. However, it is up to the verifier to decide how much to optimize the value of currency vs overhead of checking.

For instance, you suggest that the "should be executed immediately before the (verified) data is used so as to prevent invalid data being used". Does that mean you should check the credential (signatures and status) for EVERY refresh of every web page that dynamically uses the claims in that credential? No, clearly that would be overkill. Unless, of course, your use case legitimately requires such stringent checks (I could imagine some that would).

In any case, the step of verifying a credential--in the sense that VCs are "verifiable"--includes both the signature check as well as checks regarding current status. The credential cannot be said to be verified unless all checks pass. It truly is an atomic action, not one that you can assume is separable in time.

In fact, we explicitly left checking the expiry OUT of verification because there is not an agreed upon way to know for sure what the current time is. There are decades worth of stories of good people hacking the clock on their PC to get past lame time-stamp restrictions. So, there isn't a standard way to use a deterministic process to check if the expiry is past.

In contrast, you can definitively look up the current cryptographic material for an issuer (and holder; assuming both use DIDs) and check the math. You can also definitely check a status mechanism to test if a credential is still backed by the issuer. These are deterministic and decidable. In short, VCs are deterministically verifiable: check the registry for current cryptographic material, check the math, check the status. The first and last are process-driven checks, the middle is pure math.

[RieksJ]

@jandrieu I cannot argue with your first argument.

I can however with the second, and

1. I do not agree that revoking/rotating keys should render credentials invalid. A signature in a credential is to be considered (in)valid if and only if the signature key was (in)valid at the time the signature was created. Otherwise, people could sign contracts and later not be bound by it simply by revoking/rotating their keys.

2. I agree that it is entirely up to the verifier whether or not to check for revocation (and/or expiry) immediately before use. The point I would like to make here is that the current use-cases do not describe that he should have that possibility. Also, I would like to point out that current solutions such as the accumulators do not allow for this possibility: they only allow for checking for non-revocation at the time of presentation, not for any point in time thereafer. So we need a place where we anchor the need for the capability to check for revocation at any point in time between presentation and expiration of a credential.

3. I'm glad we agree that there are use-cases where the ability to check for validity immediately prior to use exist. Please note that while the use-case I provided (on parking permits) may not be very important to most of the techhies that are involved in VC discussions, yet may have a significant impact on people that such tecchies do not by nature associate with...

4. Since you bring up checking for expiry, I would also like to point out that there is a discrepancy between your argument of not agreeing on what the current time is. If it is not all that important to check for revocation after every web refresh, would actually be all that important to check for expiry after every web refresh?
   Having said that, the issue should not be about what the current time is, but it should be about allowing verifiers to have at least some ability to check for expiration. We all have passports that have expiration dates and verifiers as well as others seem perfectly capable of using it without them knowing what the current time is.
   So I would argue that the use-cases document specifiy that the verifier SHOULD have a capability for checking expiry, and a capability for checking for revocation, both of them in the absence of a direct way to communicate with either the holder or the issuer.

[jandrieu]

Deferred without prejudice. We like the intention of the clean up, but weren't able to work through the proposed PR before we hit our deadline.

[jandrieu]

@RieksJ The editors have an alternative approach that I think addresses your concerns.

We'd like to make two changes.

1. Add language to 4.3 Verify Claim to make it clear that verification checks both Authenticity and Timeliness
2. Add a Validate Claim that takes the output of Verification and interprets it according to the Verifier's business rules

The sense of both editors is that verification is about verifying that the VC represents a statement that the issuer actually asserts. That means it hasn't been tampered with AND that the issuer still stands by it, which is checking status for revocation, suspension, etc,. Once we have verified that the statement is still a quality assertion from the issuer, then the verifier can apply their own business rules to decide what to do with that statement, including any sense of expiry or revocation.

I was surprised that Verify did NOT cover the timeliness check, because I've been using that phrase of authenticity & timeliness for years.

That, in turn, highlighted that we also don't distinguish Verification from Validation, yet. So we'd like to address that clarification at the same time.

Does that seem like it would address your request @RieksJ?

[RieksJ]

@jandrieu wrote:

The sense of both editors is that verification is about verifying that the VC represents a statement that the issuer actually asserts. That means it hasn't been tampered with AND that the issuer still stands by it, which is checking status for revocation, suspension, etc,.

I agree.

Once we have verified that the statement is still a quality assertion from the issuer, then the verifier can apply their own business rules to decide what to do with that statement, including any sense of expiry or revocation.

Here I also agree, but there is still some uncovered stuff. The point I tried to make is that there may be a large time interval between the verifier having received (and verified) the VC, and the verifier using its content for some purpose. For the verifier, the latter is more important than the first, because they could make decisions based on VCs that checked out when they were received, but in the meantime expired, got suspended, or revoked. This could be illustrated by adding some text to the 2nd paragraph of the expert dive instructor scenario (5.2), where it makes explicit that the current status includes ‘revoked’ (which is obvious to us, but may not be that for readers). It should also say that whenever Pat is scheduled to take a group of divers on NOAA sanctioned dives, NOAA will also do a check, to ensure that Pat’s credentials haven’t been revoked, and NOAA may cancel the dive if it assesses the resulting risk to be unacceptable.

I was surprised that Verify did NOT cover the timeliness check, because I've been using that phrase of authenticity & timeliness for years.

I’ve always wondered about that, but not being a native English speaker, I thought it had to do with the credential being presented ‘in time’ (immediately, or when the verifier needs it). That would not be a characteristic of the VC itself, but merely a statement saying that VCs are a good way to present data ‘on time’ or ‘in time’. It never was a big deal to me.

That, in turn, highlighted that we also don't distinguish Verification from Validation, yet. So we'd like to address that clarification at the same time.

It would be really great to have some text devoted to the distinction between verification (as defined in the VCDM) and validation (also sort-of defined there, but explicitly declared out of scope). While verification (signature checking, to put it bluntly) is of course important, validation is what really matters. I’ve done a write-up of the context of all that which I’m happy to share in case you’re interested.

Does that seem like it would address your request @RieksJ

As I mentioned before, I think the use-case of checking revocation is still good to have. First, the verify claim use-case would use the ‘checking revocation’ use-case, as checking revocation may also need to be done some (long) time after the VCs are received/verified. Second, I think it is a very good idea to have a set of the very basic VC use-cases that is complete (that’s why I also did the other issues), which provides readers with an overview that should allow them to better follow the more complicated scenario’s.

[jandrieu]

Ok. I'll put together a PR that illustrates what I was proposing and we can continue the conversation there.

[TallTed]

@RieksJ -- I strongly advise addition of quotation-indents/-markers, and a blank line between a quoted section and a response section, as it is currently rather difficult to parse your message in either the GitHub web interface or the email they dispatch.