Issuers may express a Time to Live on the credential

[stonematt]

@David-Chadwick your comment in issue #135 about having to be online to verify the referenced credential is a larger challenge in general. VC should be verifiable w/out going to the source in general. This protects the VC from becoming useless if the issuer site goes offline. If Issuers care to limit how long a credential can be trusted without live verification from the source, the Issuer must include something like a Time To Live in the credential to indicate how long it's valid before the data is considered stale. --- TTL is different than the expiration of the credential itself. This has better privacy protection than a revocation list, and is less exposed to DDOS attacks.

Consider:

• Andy's driver's license expires in 2 years and has a VC that shows the expiration date in 2020.
• When the state cuts the VC, they put at 60day TTL on the credential, with a "refresh URL"
• When the verifier receives the VC, as long as the signatures validate and it's within 60d, the credential is considered valid
• If the verifier receives a VC that was created more than 60d ago, the verifier should ignore it and ask for a refresh.
• Later, in our protocol, the Holder should have a way to "refresh" the TTL and re-share, also the ability to "refresh" could be a capability that's granted by the Holder to the Verifier.
  -- Consider a Professional (Holder) giving a license (VC) to an Employer (Verifier) and granting them the permission to verify license status on demand, as long as the professional continues employment.

[David-Chadwick]

@stonematt I agree that the issue of remote retrieval is a much larger problem in general than fetching a referenced credential. It covers all new information that extends the base standard for VCs and is defined somewhere else online. Your idea for a TTL property is a good one, and whilst it does not address the general issue of remote retrieval, it does partially cover the revocation/staleness issue. However, what to do after the TTL expires is a separate issue, and can be solved in a variety of ways such as: reissuing the credential (short TTL and non-revocable), periodically publishing a CRL at least every TTL, credential status stapling (cf OCSP stapling). So I think we could add a TTL property independent of the credential status method.

[msporny]

Time to Live is probably a bad name for this feature... I think what we're really going for is something that already exists in HTTP - the Cache Control header:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

Let's not re-invent the wheel and just re-use the header name and the acceptable values of the field as they seem to map cleanly to the use case presented above.

As for the refresh URL, that's a protocol level thing, but perhaps we can introduce a refresh URL that one must authenticate to in order to use. In general, we want to make it such that the holder SHOULD authenticate to refresh and the issuer SHOULD NOT allow verifiers to hit the service due to privacy issues.

Here's how we deal w/ @stonematt's scenarios:

Andy's driver's license expires in 2 years and has a VC that shows the expiration date in 2020.

"expirationDate": "2020-01-01"

When the state cuts the VC, they put at 60day TTL on the credential, with a "refresh URL"

"cacheControl": "public, must-revalidate, max-age=5184000",
"cacheRefreshService": "https://example.org/credentials"

When the verifier receives the VC, as long as the signatures validate and it's within 60d, the credential is considered valid

The verifier checks the cacheControl value associated with the credential, checks public (it can cache the credential), must-revalidate (it must revalidate within the time period), max-age (the time from the date of credential issuance must be less than 60 days).

If the verifier receives a VC that was created more than 60d ago, the verifier should ignore it and ask for a refresh.

This is what the must-revalidate directive does.

Later, in our protocol, the Holder should have a way to "refresh" the TTL and re-share

The Holder's credential repository software will check the cacheControl value from time to time and automatically request a new credential if the cache is stale for any reason. The cacheRefreshService URL is used for this, where the credential identifier is tacked onto the end of the cacheRefreshService URL.

also the ability to "refresh" could be a capability that's granted by the Holder to the Verifier. -- Consider a Professional (Holder) giving a license (VC) to an Employer (Verifier) and granting them the permission to verify license status on demand, as long as the professional continues employment.

I suggest we do capability delegation for verifier refreshing off to a version 2 of the protocol... we don't have the basic building blocks in place to do that. We can put a note to this effect in the specification.

I'll submit a PR for this proposal now.

[msporny]

Having written PR #199, I now believe that this feature is unnecessary and creates further complexity in the specification. The problem is that the issue presumes that TTL is a good idea when we have other mechanisms that accomplish the same thing as a TTL.

I suggest we do not pull in PR #199 and close it, not support the concept of TTL in this version of the specification, and submit a new PR for refreshService.

[stonematt]

I want to go back to the use case to make sure we're on the same page. The concept of caching probably isn't right. There is a pretty common business/market scenario in use today by professional licensing organizations where the verification process represents a significant portion of their revenue. When I use the term TTL, I may have gotten us going down the wrong path.

The market scenario requires the verifier to pay for a new verification after a certain time period. A simple scenario is like this:

• Pat holds a license that expires on 31 DEC 2019
• Upon payment by Pat, the Board of Licensure issues a VC to Pat on 25 JUL 2018 since their policy is that a verification is good for 30days, the VC expirationDate is 24 AUG 2018. This is the date that the verification ceases to be valid, regardless of the content of the underlying claim.

Is this the right interpretation of the current data model?

• The claim inside the VC would have the license name, license issue date (sometime in the past) and license expiration date 31 DEC 2019
• Outside of the claim details, the VC issuanceDate is either 25 JUL 2018 (when the VC was created), or the date in the past that Pat earned the license (another discussion topic?) and the VC expirationDate is 24 AUG 2018

I don't think we block the issuer from implementing this, so we may meet the use case as the data model sits today. If it does in fact work this way, it adds some confusion to the meaning of "issueanceDate" and "expirationDate" in practice.

The data model defines issuance date as "Note that this date represents the earliest date when the information associated with the claim property became valid." which is contrary to the details above. This issue is primarily about expirationDate, if we need to discuss the meaning of issuanceDate further, let's open another issue.

[msporny]

@stonematt wrote:

• The claim inside the VC would have the license name, license issue date (sometime in the past) and license expiration date 31 DEC 2019
• Outside of the claim details, the VC issuanceDate is either 25 JUL 2018 (when the VC was created), or the date in the past that Pat earned the license (another discussion topic?) and the VC expirationDate is 24 AUG 2018

The answer can be "either one"... which may or may not be a good thing. That is, you can implement both of the above with the current data model and exactly what is implemented is up to the market vertical doing the implementation.

That said, I do agree that this is an important use case and adding a refreshService in the presentation addresses the problem created by short-lived credentials. So, Digital Bazaar will be implementing this feature whether or not it is standardized. The group is really shooting itself in the foot by not putting this in the core spec... but the great thing about the data model is that it's not really going to have that bad of a long-term effect except for a little bit of non-interoperability in the early days as we all implement refreshService in slightly different/incompatible ways.

[stonematt]

@msporny I suggest we label this issues as "defer" and make a new label for "refreshService" so we can come back to these topics in v2 of the spec.

[stonematt]

Agree that the TTL concept be deferred to v2. Basic refreshService is addressed as an Advanced Concept in PR #210

The TTL concept may be served by something like a Terms of Use approach as well...

[kdenhartog]

This was discussed on the WG call today. We decided that this will be defered to v2 since it's not fixing a bug and is instead looking to extend the current spec.

[iherman]

The issue was discussed in a meeting on 2021-06-14

• no resolutions were taken

View the transcript

3.2. Issuers may express a Time to Live on the credential

See github issue #164.

Brent Zundel: previous group felt it should be deferred

Kyle Den Hartog: +1 seems to be an extension at this point

Manu Sporny: Agree with brent that it should be deferred

Brent Zundel: comment - a new feature, out of scope for the group
… no objections - issue 164 marked deferred

[Sakurann]

the direction discussion in this issue has taken is very different from the original question raised. suggest close this issue and re-open a new issue if we want to discuss extending refreshService in v2

[iherman]

The issue was discussed in a meeting on 2022-08-10

• no resolutions were taken

View the transcript

4.7. Define v2 context (issue vc-data-model#164)

See github issue vc-data-model#164.

Kristina Yasuda: Manu commented that this belongs not in the data model, but transport protocol or other places..

Orie Steele: +1 to keeping transport protocol concerns out of the data model, and closing.

Manu Sporny: +1 to close.

Kristina Yasuda: Marking as "pending close".

[brentzundel]

No comments since makred pending close, closing.