Perhaps the biggest challenge with multiple credential / assertion presentations is managing overlapping, or disjoint, or unbounded validity periods.
For each signed object, the following fields can be present iat, nbf, exp.
These fields are typically optional, so by default they could remain optional.
However we currently have normative language that attempts to align them and constrain them, for example that a status should not be issued before a credential, or that a status should not expire after a credential expires.
There are cases where a credential might be issues, and then status used to incrementally extend its expiration, for example:
Perhaps the biggest challenge with multiple credential / assertion presentations is managing overlapping, or disjoint, or unbounded validity periods.
For each signed object, the following fields can be present
iat,nbf,exp.These fields are typically optional, so by default they could remain optional.
However we currently have normative language that attempts to align them and constrain them, for example that a status should not be issued before a credential, or that a status should not expire after a credential expires.
There are cases where a credential might be issues, and then status used to incrementally extend its expiration, for example:
vc: { iat: 0 }, sa: { iat: 1, exp: 2 } ... sa: { iat: 3, exp: 5 } ....
There are cases where a status can only be requested for the validity period of the credential:
vc: { iat: 0, exp: 10 }, sa: { iat: 1, exp: 2 } ... sa: { iat: 3, exp: 5 } .... (will never have exp greater than 10)
There are cases where issuance time and activation time are not the same (like post data checks):
vc: { iat: 0, nbf: 5, exp: 10 }, sa: { iat: 1, exp: 2 } (appears valid, but nbf 5 is after exp 2, so this status will not be valid)