-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why HAIP implies that there are temporal validation rules for iat
when it has none, and at the same time does not mention nbf
at all?
#164
Comments
For what it's worth, the validation logic for
We could add similar language to this spec. |
Is there an authoritative set of use cases stashed somewhere? Perhaps this is too contrived, but would it make sense pre-issue a replacement credential such as an international passport without automatically invalidating an existing credential? Generally, an individual isn't allowed to have more than one valid passport, but there may be reasons to not invalidate an existing passport when the new one is issued. Or what about, say, an event pass which is valid for only one day of a multi-day event (like a one-day pass for Identiverse)? One could argue that validity periods could be embedded in issuer-specific credential metadata, but I kind'a like a standardized way to express this. A Wallet could also provide a credential selection UX that hides or de-emphasizes creds which aren't (yet) in their validity range. [As an aside, how many of use just love the idea of sending in our still-valid physical passport to a government agency to hopefully be replaced by a new one at some vague future time? A new digital passport being issued before the existing one expires seems pretty attractive and it may make sense to not invalidate an existing credential at the time of replacement.] |
I do not know if it needs to be considered in the context of HAIP, but I have recently reviewed draft version 0.0.6 of ETSI TS 119 472-1 Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestations of Attributes; Part 1: General requirements standard. That draft standard has requirements that say that EUDIW ecosystem attestations (EAAs, QEAAS and PuB-EAAs) must express their validity period with two instant times. The same draft standard also specifies this further by saying that these instant times shall be expressed with |
Currently section ‘Validity Period of the Signature and the Claim Values’ has this to say about
iat
claim:Why is it implied that
iat
claim has temporal validation rules? The JWT standard does not define any rules foriat
in section 4.1.6. "iat" (Issued At) Claim.Meanwhile, the JWT standard has temporal validation rules for
nbf
claim in section 4.1.5. "nbf" (Not Before) Claim, but HAIP does not mention that claim.I created a pull request #165 that proposes adding
nbf
to the claims table in section ‘SD-JWT VCs’ and replacingiat
in section ‘Validity Period of the Signature and the Claim Values’ withnbf
.The text was updated successfully, but these errors were encountered: