implement document expired verifier

[arpentnoir]

This is a feature proposal

Context

• Some documents issued may have expiry dates (e.g. trade related documents such as Certificate of Origin, CITES permits)
• expiry could be handled in one of two ways:
  • leave it up to the consumer to know about the OA payload structure and implement it's own rules about expiry, or
  • implement expiry at the OA wrapper layer

I'm raising this proposal under the assumption that, document expiry is general enough to qualify as something that might better be implemented at the OA layer, and that here (rather than as a document specific extension of this library) is a sensible place to do this.

Proposal

Implement a 'document_expired' verifier which returns a verifier status of INVALID for documents containing a payload with an expiry date in the past

Problems

How do we allow for the creation of a wrapped open attestation document containing a document expiry verifier fragment with an expiry date that does not diverge from an expiry date given by the raw payload?

let's say we have a document something like this:

{
  "certificateOfOrigin": 
  {
    "id": "1234567",
    "issueDateTime": "2021-02-22T07:42:01.149943+00:00",
    "name": "Certificate of Origin",
    "expiryDate": "2021-02-22T00:00:00+00:00"
  }
}

and we want our wrapped document to contain a verifier fragment that allows the verifier to find and compare the expiryDate to current date to determine validity. How do we do that in a flexible way that does not impose limitations on the structure of raw documents?

perhaps the document expiry verifier fragment could contain a date format and json path expression to the payload element that represents the document's expiry date?

e.g. the fragment could look something like:

{
  "expiry": 
    {
      "path": "$certificateOfOrigin.expiryDate",
      "format":"YYYY-MM-DDThh:mm:ss.TZD"
    }
}
 

the verifier could then look at the path and format values, extract from the payload and compare to, what?
which brings me to...

How do verifiers determine the current datetime?

there might be multiple acceptable options. maybe the fragment could contain a method which could allow the verifier to determine the current date however it sees fit, or it may specify some mechanism like:

• look at the timestamp of the most recently mined ethereum block? (assuming we don't need to be very accurate for things like document expiry...)
• verifier uses own system time
• http://worldtimeapi.org/ or similar?
• some service stipulated by the document issuer in a similar manner to how renderers are referenced?

🤷‍♂️

[Nebulis]

Hi, and thanks for your proposal.

On my side I'm agreeable to have something in open-attestation to support date validity. Some insights:

• Before creating a verifier, we need to support it at the schema level (we need to know which fields denote data validity). I prefer that we are as close as possible to W3C VC spec. I would suggest that we use issued / validFrom / validUntil instead of issuanceDate and expirationDate which have semantic issues. Fields to be added at the root of the document.
• In oa-verify, we should not add this new verification method as mandatory. Indeed the meaning and implication of an expired document vary greatly depending on the use cases. We can leave it to verifiers (like OpenCerts / TT) to decide what they want to do with an expired document (should it still be viewable for instance)
• Adding new fields like this is actually a bit tricky. For instance let's say we add issued / validFrom / validUntil. But what about the previous certificates that does not contain the value ? We might be tempted to ignore them, but it's not that simple. OpenAttestation allows for selective disclosure, but we don have a user to hide this information, otherwise an invalid document might become valid. That means that such a change will introduce a breaking change and the creation of a new schema, to differentiate old and new certs
• About the date, not a problem, users must use timezone, like indicated in rfc 3339 or iso8601. If they don't they take the risk of misinterpretation of the real date.

[arpentnoir]

thanks for your response @Nebulis

perhaps this issue will be addressed by v3 anyway? I see that the v3.0 schema includes the validUntil/expirationDate fields.

what is the planned approach to handling credential expiry for v3? i.e. is it the intent that verify will return an invalid status for credentials being verified past the validUntil date, or is it assumed that consumers can implement handling of credential expiry, for an otherwise valid credential?

[Nebulis]

We will address the schema indeed, as for the verifier our opinion remains:

In oa-verify, we should not add this new verification method as mandatory. Indeed the meaning and implication of an expired document vary greatly depending on the use cases. We can leave it to verifiers (like OpenCerts / TT) to decide what they want to do with an expired document (should it still be viewable for instance)

Let's leave the choice to verifiers. But definitely can create a verification method from oa-verify to help verifiers :)