Spec probably needs to outline rules with refresh and time sensitive properties on a Vc

[aljones15]

When a Vc is refreshed should time sensitive properties such as:

• expirationDate
• refreshService.validUntil
• refreshService.validAfter

be updated? If these time values should be updated, who decides the new interval?

Server Side interval algorithms:

1. Should the interval be calculated using the issuanceDate and the original expirationDate or validUntil date?
2. Should a refresh service have predetermined values for validUntil and validAfter defined in seconds after the current date?

Client Side interval algorithms (seems weak):

1. when posting to the refresh service an options object is provided with validUntil & validAfter and maybe expirationDate.
2. A VerifiablePresentationRequest with query from the refresh service could ask for a Vc signed by the issuer or refresh service providing the intervals for the refresh. (this ties in with issue: Does the spec need normative statements for the Verifiable Presentation Request? #5)

Can a Vc with only refreshService.validAfter defined by refreshed indefinitely once the validAfter date has occurred?

[msporny]

Attempts at a first set of answers below:

When a Vc is refreshed should time sensitive properties such as:

• expirationDate
• refreshService.validUntil
• refreshService.validAfter

be updated?

Yes, and don't forget issuanceDate, too.

If these time values should be updated, who decides the new interval?

It is the Issuer App, that is, the application that contains the business rules for the particular type of credential that should set the values. The values should be set before a call to the Issuer Service is made. For a description of this terminology, see https://w3c-ccg.github.io/vc-api/#apps.

Server Side interval algorithms:

1. Should the interval be calculated using the issuanceDate and the original expirationDate or validUntil date?

Not in all cases. We should have the ability to run arbitrary code to determine the new issuance, expiration, and validity dates.

2. Should a refresh service have predetermined values for validUntil and validAfter defined in seconds after the current date?

No, we shouldn't have pre-determined values. Again, this is highly dependent on the type of credential being issued, as well as the Issuer's business logic. We need to think deeply about how we enable this such that someone working w/ a UI could set values based on their issuance needs. For example, we might want to specify these durations as ISO 8601 durations. For example, a "credential lifetime" could be "P1Y" from issuance (one year from issuance)... a "refresh window" could be "P1M" (one month before the expiration date)?

Client Side interval algorithms (seems weak):

1. when posting to the refresh service an options object is provided with validUntil & validAfter and maybe expirationDate.

We could do that, or we could just include it in the VC. What are the downsides with just including that information in the VC?

2. A VerifiablePresentationRequest with query from the refresh service could ask for a Vc signed by the issuer or refresh service providing the intervals for the refresh.

It could, but the refresh service really should know what those intervals are (since it is the authority on how often things should be refreshed). It should be able to get this information from /somewhere/, but ultimately, you probably shouldn't allow the client to send the refresh interval (even if it's signed) as that could lead to an external attack. See https://redis.com/docs/json-web-tokens-jwts-are-not-safe/

(this ties in with issue: Does the spec need normative statements for the Verifiable Presentation Request? #5)

I wrote up a response to #5.

Can a Vc with only refreshService.validAfter defined by refreshed indefinitely once the validAfter date has occurred?

Ultimately, that decision is up to the refresh service logic. By default, my assumption would be "yes", because the issuer didn't provide a "validUntil" date. However, the real question is whether or not the refresh service can override both the validFrom and validUntil values... and the answer there should be "yes", because whether or not to refresh a credential is ultimately up to the refresh service... it can choose to override values that it set (in some cases).