Allow to set expiration date on a per-credential basis

[docktordreh]

Context and Use Case

I am currently working on a Master’s thesis that models an enterprise credential lifecycle scenario using verifiable credentials.
The scenario reflects common access-governance requirements in enterprise collaboration environments.

In this scenario, a business-facing application manages access to project-related documents for internal staff and external partners.
Access control is done via verifiable credentials, which are used for fine-grained authorization decisions.

A central business process is partner onboarding and offboarding:

• External partners are granted temporary access to selected project documents
• Access rights are represented by issuing a verifiable credential
• Collaborations are time-bounded by contract or project duration
• Once a collaboration ends, access must reliably expire or, in the case of premature termination, the credential must be revoked

Problem Description

While credential revocation is already supported and suitable for early termination scenarios, the use case also requires to set the expiration date on a per-credential basis:

• Each issued credential should support an explicit expiration date
• The expiration should be configurable per credential, not enforced via a global or schema-wide policy
• Current behavior hardcodes an expiration of +2 years from issuance

In the use case, revocation is an active administrative decision, whereas expiration is a planned, contractually defined lifecycle boundary.

Currently, One Core hardcodes the expiration date (lib/one-core/src/provider/credential_formatter/mapper.rs, credential_data_from_credential_detail_response, let valid_until = valid_from + time::Duration::days(365 * 2);).

Desired Capability

From an enterprise credential lifecycle perspective, it would be nice to:

• Specify a valid-until / expiration timestamp when creating a credential
• Persist this expiration as part of the credential state

Question

Is supporting per-credential expiration dates a use case that aligns with One Core's intended credential lifecycle model?
Feel free to let me know as I have already successfully implemented it.

[svenstucki-pcv]

Dear @docktordreh

Thanks for your inquiry and detailed analysis. Indeed, the current handling of credential expiration dates is too simplistic and not flexible enough for advanced use cases. We are aware that we will need more capabilities there, but have not decided on a final approach yet.

It is important to distinguish between expiration on the business and the technical layer. For example, even in our current implementation of mdocs, the issued MSOs are short-lived (configurable) and will expire, but the credential itself stays active in our solution. Similarly, with batch-issuance and wallet attestations, the technical credentials will have a shorter validity than the corresponding credential (on a business logic level).

With the current release, we are removing the hard-coded values and replace them with config. We are considering a fully dynamic lifetime as required by you, but don't have a release date estimate for this.

For now, I would recommend to manage the validity in your application (e.g. through an expiration timestamp in the attributes) and business logic.

[docktordreh]

Thank you for your thoughts @svenstucki-pcv.

It is good to hear that you are thinking about a dynamic lifecycle. Configuration is a great step towards this.

While I have also thought about separating technical data and business claims (e.g., by adding a validUntil claim), I think verifiers are supposed to check the exp header (we are using SD-JWT VCs). RFC 7519 mentions:

The "exp" (expiration time) claim identifies the expiration time on
 or after which the JWT MUST NOT be accepted for processing.

Although this is not specified in the OID4VP specification.

I'm currently using a fork where I've added a validUntil field to the credential model, allowing me to pass an optional expiration date during credential creation, which is then passed to the underlying functions.

[svenstucki-pcv]

Hi @docktordreh

To be clear, we fully agree and do validate and enforce the exp claim during verification.

My point was simply to clarify that this represents the technical expiration of the credential only. It does not necessarily reflect the expiration of the corresponding higher-level (logical) credential (but must always be shorter of course). This is already common with mdocs, where the MSOs are short-lived only and regularly reissued. But the same will apply to other credential formats as well. This part will still need additional concept work on our side.

Your approach sounds good to me and I'm very glad to read that you were able to adapt the solution to your needs.