Expiration Dates on Standards, can Evergreen deprecate features, etc.

I wrote this issue up in regards to my request that the VCWG consider
having an expiration date for cryptographic security & privacy standards,
which I think may be useful to inform Evergreen Process discussions:

https://github.com/w3c/vc-data-model/issues/253 :

I think that this issue should be changed to request the TAG or the
W3Process "Evergreen Standards" group to give advice on it.

The scenario I'm trying to avoid is a specification that has "international
standard" status but should be deprecated for security or privacy reasons.

As the co-editor of IETF TLS 1.0 from 1995 to it's release in the beginning
of 1999, I was quite disappointed when there were serious server downgrade
attacks against TLS in 2017 (almost 20 years after release of 1.0) using
cryptography and versions that should have not been in use for over a
decade, but were still "part of the standard" despite there being
subsequent 1.1 and 1.2 releases. In retrospect, I wish not only the spec
itself, but many of its normative features such as ciphersuites, had
expiration dates on them, even if 10 or 20 years ahead. If a spec or
feature is still strong after a decade they can be renewed with a new
expiration date.

My concern may not applicable to this specific VC specification, as it does
not contain normative cryptographic information, but there may be privacy
best practices discovered in the future that warrants deprecating this spec
in 20 years.

Part of my concern that an expiration should be in the final version of a
W3C spec is that this WG ends after the CR is approved. If in an Evergreen
process (such as is being discussed in the WG-Process WG) where they can
deprecate a spec version or features in a spec, I'd feel this is less
necessary.

I am not asking for this issue to be a CR-Blocker, nor should it be a
CRExit-Blocker.


-- Christopher Allen