10 ms·

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

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.

NovemberWhiskey 4y ago
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.
- lxgr 4y ago
  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. This would save you a trip to the issuer.
  - NovemberWhiskey 4y ago
    Right - that's the "drinker's permit" concept I'm talking about here: https://news.ycombinator.com/item?id=33430005 https://news.ycombinator.com/item?id=33430005
  - dwaite 4y ago
    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.
dwaite 4y ago
> 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.

NovemberWhiskey 4y ago

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.

lxgr 4y ago
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. This would save you a trip to the issuer.
- NovemberWhiskey 4y ago
  Right - that's the "drinker's permit" concept I'm talking about here: https://news.ycombinator.com/item?id=33430005 https://news.ycombinator.com/item?id=33430005
- dwaite 4y ago
  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.

dwaite 4y ago

> 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.