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.
Maybe this is a silly question. But wouldn't this just mean that the ID would need to be updated very regularly? Like at least every year if not more frequently?
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.
You don't update that property unless there would be a need to prove the age was above some other number. Otherwise I think you're on the right track. As you said, you'd update it when you turned 18 or 21 etc.
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.
The DMV (or whoever issues widely accepted identity documents in your country) could also provide a service that can exchange precise assertions to more private ones, i.e. one that allows the following transaction:
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.
For mobile drivers licenses in ISO 18013-5, the credential is a signed list of salted hashes, each representing a distinct named attribute. You release the credential as well as whatever attributes which were requested.
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.
> Maybe this is a silly question. But wouldn't this just mean that the ID would need to be updated very regularly? Like at least every year if not more frequently?
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.
Surely you'd store their birthdate (or maybe birth year and month for privacy reasons). Then you only allow people who you know are older than 21, those born before (not in) 2001-11 (based on currentYear of 2022). With the magic of modern JavaScript, this shouldn't be too hard:
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.")
e: I didn't fully read OOP's comment about not wanting to reveal age, however I still feel that YYYY-MM is a valid option for age verification. It allows for the most privacy while impacting the smallest group of people, and in those cases you would effectively need to be 21 and a month old to enter these bars, without some other form of legal ID.
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?
Who is the "you" in this? The party that knows the truth of your personal data isn't the same party that you want to rely on your personal data.
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.
Heck, I can't remember how old I am. Pretty sure I'm over 21 though, and most authorities would agree after a cursory visual inspection. There are also folks who:
* 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.
Ignoring the specific example given, JavaScript Date objects use zero-based months depending on how you construct or interact with them, so I'm assuming the OP was thinking of a zero-based example and just wrote it out using 08 in the string.
there is also the problem that in some locales the first day of the week is thought to be Sunday rather than Monday, so regardless of 0-indexing or not, we can't even agree on that IRL :-D
https://www.w3.org/TR/vc-data-model/#favor-abstract-claims