You could issue the credential with an "ageOver" property set to 21; use of abstract claims like that is actually a non-normative preference in the W3C standard.
In the theoretical use case of drinking, I couldn't just goto the bar on my 21st birthday, provide my ID, and buy a drink. I'd have make sure that I did whatever process was required to update my Verifiable Credential first?
I get the abstraction is great from a PII standpoint, and that likely this wouldn't be a big roadblock since this is all digital anyways. One assumes that the user could just press a big ol "refresh" button and be done in a few seconds. But still curious.
In the US, 21 is the "prove you can buy liquor" age and there's seldom a need to prove anything higher, outside of some unusual cases like becoming a member of Congress or President or something. No-one cares if you're 22 or 24 or 43.
You provide a document stating that "Mr. Foo Bar is depicted on this photo and was born on 1990-04-01" signed by them, and get one that just says "the person depicted on this photo is over 18/21", also signed by them.
This would save you a trip to the issuer.
You can disclose your full name and your birth date, or just the boolean value that you are over 21, depending on the use case.
Of course, many of these scenarios would be more logically served with a digital version of a national ID card or passport, but some countries use driving licenses in lieu of such concepts.
Depends on the relationship between the person and the issuer, which really means it depends on the use case.
For a credential that has to be usable independent from the issuer, such as wanting to be able to use a transcript even if the school goes bankrupt, you would generally want something long lived. The issuer might maintain a revocation mechanism, which might even be on a shared ledger so that it stays available even if the business entity goes away. It might be difficult to take the approach of precomputed predicate attributes, so you would be more inclined to use techniques like range proofs. You might also want to use cryptographic techniques to anonymize the signatures, so that the underlying crypto of the signed message doesn't become a correlation vector.
For a credential that is actively maintained as part of a relationship between two entities (which could include many things like citizenship, proof of driving and medical services/insurance proof), you can just have a short lived timespan for which the person has to fetch a new version. You don't necessarily need revocation except in the cases where you _need_ to have the information invalidated before it would naturally expire. You can also vend a 'stack' of credentials so that they can be used in multiple places without being linkable.
For this second case, you can just say 'age_over_21' as a statement which will be true for the day/week/month that that credential is valid to be presented. They would set the credential to become stale the day of your birthday, and your wallet would just fetch a new batch indicating the 'true' value.
This is the approach taken for instance by the ISO digital driving license spec.
let birthday = "1998-08" # This value is taken from the user's verified credentials, in my case September 1998.
let ageRestriction = 21
let legalDate = new Date(new Date().setFullYear(new Date().getFullYear() - ageRestriction))
let birthdayDate = new Date(birthday)
if (legalDate > birthdayDate) console.log("Is that cash or card?")
else console.log("Sorry, you're not old enough.")
e2: Reading through the article after commenting (I know, I'm terrible and you can all violently detest me if you wish), there is an "ID card" example which clearly states the user's date of birth. Surely this is a prime use-case for OOP?
The idea here is, say, the DMV in your state knows your age. But you don't want to show your driver's license credential which includes your home address and exact birthdate at a bar, because it's not their need-to-know.
So you can ask the DMV to issue you with a "drinker's permit" which only has your photo and ageOver=21. A bar just validates you match your picture and knows you're of legal drinking age.
* Can only guess at the day, month, and/or year of their own birth.
* Cannot currently tell you their date of birth (e.g. incapacitated, incommunicado, unconscious, absent, or forgot. what year is it?)
* Cannot prove their date of birth (e.g. records destroyed)
* Mix up their relatives date of birth (the probability of this approaches 1 asymptotically as the family size increases)
* Use a different date format to you, with consequently ambiguous interpretation
Similar impedance mismatches between information and permission exist in almost all authorization domains. Consequently, the only credentials with general applicability are those capable of asserting a right or validating a claim, not those that merely sign data.