#Validity Period in Verifiable Credentials

#Introduction

In the context of Verifiable Credentials (VCs), a validity period defines the time range during which a credential is considered valid. Similar to how physical credentials like passports or driver's licenses have expiration dates, digital verifiable credentials use validity periods to communicate their temporal boundaries.

Validity period is a fundamental concept in the Verifiable Credentials ecosystem as it provides essential temporal context for the claims being made in a credential. It helps verifiers determine whether a credential should be considered current and applicable at the time of verification.

#Validity Period Components

The W3C Verifiable Credentials Data Model (VCDM) specification defines two primary properties to express the validity period:

#validFrom

The validFrom property expresses the date and time when a credential becomes valid. This property serves as the starting point of the credential's validity period.

• Type: An XML Schema dateTimeStamp string value (a timestamp formatted according to RFC 3339 with a timezone).
• Format example: "2010-01-01T19:23:24Z" (representing January 1, 2010 at 19:23:24 UTC)
• Optional: While recommended, this property is not strictly required.
• Meaning: Represents the earliest point in time at which the information in the credential becomes valid.

#validUntil

The validUntil property expresses the date and time when a credential ceases to be valid. This property serves as the ending point of the credential's validity period.

• Type: An XML Schema dateTimeStamp string value.
• Format example: "2025-01-01T19:23:24Z" (representing January 1, 2025 at 19:23:24 UTC)
• Optional: This property can be omitted for credentials without an explicit expiration date.
• Meaning: Represents the latest point in time at which the information in the credential is valid.

#Temporal Relationships

When comparing dates and times for validity periods, the calculation is done "temporally," meaning that the string values are converted to temporal values (points on a timeline) before comparison.

The specification requires that if both validFrom and validUntil are present, the validFrom value MUST express a point in time that is temporally the same or earlier than the point in time expressed by the validUntil value. This ensures that the validity period is logically consistent.

#Implementation Guidelines

#dateTimeStamp Format

Both validFrom and validUntil properties must use the XML Schema dateTimeStamp format, which includes:

• A date (year, month, day)
• A time (hours, minutes, seconds)
• A timezone indicator (either "Z" for UTC or an offset like "+01:00")

The timezone indicator is critical for ensuring unambiguous interpretation of the timestamp across different systems and geographical locations.

#Default Behavior

If neither validFrom nor validUntil are present, the verifiable credential's validity period is considered indefinite. In such cases, the credential is assumed to be valid from the time it was created.

If only validFrom is present without validUntil, the credential is considered valid from the specified time onward, with no defined expiration.

If only validUntil is present without validFrom, the credential is considered valid until the specified time, with an implied start from the credential's creation time.

#Implementation Constraints

When implementing validity periods, systems should adhere to these constraints:

1. The validFrom time must be the same as or earlier than the validUntil time (when both are present)
2. Timestamps must include timezone information
3. Systems should be prepared to handle all variations (both properties, either property, or neither property)

#Validation Considerations

During the verification process of verifiable credentials, validity period validation is a crucial step:

1. Temporal Verification: The current time should be compared with the validity period to determine if the credential is currently valid.
2. Handling Time Zones: Implementations must correctly handle timezone information in the timestamps.
3. Time Precision: Systems should consider the level of time precision required for their specific use cases.

A credential is considered temporally valid if:

• The current time is equal to or later than the validFrom time (if present)
• The current time is earlier than the validUntil time (if present)

#Security and Privacy Implications

#Short-lived Credentials

Credentials with short validity periods require more frequent renewal, which can create privacy implications:

• Correlation Risk: When credentials have short lifespans and automatic renewal mechanisms, issuers might be able to correlate a holder's behavior by tracking the frequency and timing of renewals.
• Freshness vs. Privacy: Short-lived credentials provide better assurance of freshness but may compromise privacy by requiring more frequent interaction with issuers.

#Long-lived Credentials

Credentials with long validity periods or indefinite validity present their own considerations:

• Revocation Complexity: Longer-lived credentials may require more complex revocation mechanisms since they remain valid for extended periods.
• Privacy Advantage: May provide better privacy by reducing the need for frequent renewals and interactions with issuers.

#Best Practices

1. Appropriate Duration: Choose validity periods appropriate to the type of credential and its intended use.
2. Clear Communication: Clearly communicate validity periods to all ecosystem participants.
3. Timezone Awareness: Always include timezone information in timestamps.
4. Privacy Considerations: Be aware of how validity period choices impact privacy.
5. Validation Logic: Implement comprehensive validation logic that handles all validity period scenarios.

#Examples

#Example 1: Credential with Both Properties

{
    "@context": ["https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2"],
    "id": "http://university.example/credentials/3732",
    "type": ["VerifiableCredential", "ExampleDegreeCredential"],
    "issuer": "https://university.example/issuers/14",
    "validFrom": "2010-01-01T19:23:24Z",
    "validUntil": "2020-01-01T19:23:24Z",
    "credentialSubject": {
        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
        "degree": {
            "type": "ExampleBachelorDegree",
            "name": "Bachelor of Science and Arts"
        }
    }
}

#Example 2: Credential with Only validFrom

{
    "@context": ["https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2"],
    "id": "http://university.example/credentials/3732",
    "type": ["VerifiableCredential", "ExampleDegreeCredential"],
    "issuer": "https://university.example/issuers/14",
    "validFrom": "2010-01-01T19:23:24Z",
    "credentialSubject": {
        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
        "degree": {
            "type": "ExampleBachelorDegree",
            "name": "Bachelor of Science and Arts"
        }
    }
}

#Example 3: Credential Without Validity Period

{
    "@context": ["https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2"],
    "id": "http://university.example/credentials/3732",
    "type": ["VerifiableCredential", "ExampleDegreeCredential"],
    "issuer": "https://university.example/issuers/14",
    "credentialSubject": {
        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
        "degree": {
            "type": "ExampleBachelorDegree",
            "name": "Bachelor of Science and Arts"
        }
    }
}

#Conclusion

Validity periods are a crucial element of the Verifiable Credentials Data Model, providing temporal context for the claims contained within credentials. By defining clear start and end times for a credential's validity, ecosystem participants can make informed decisions about when to trust and use the credential's information.

Implementers should carefully consider the security, privacy, and usability implications of their validity period design choices, ensuring they align with the specific requirements of their use cases and the broader goals of their credential ecosystem.

#References

1. W3C Verifiable Credentials Data Model v2.0: Validity Period