-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Highly dynamic information should have short expiry times #18
Comments
On the contrary, short lived non-revocable claims can be more privacy preserving than long lived revocable ones, since the inspector does not have to contact the issuer to retrieve revocation information. |
The frequency of use is related to #14, so it's still an issue.
Doesn't this assume centralized revocation lists? This isn't an issue for decentralized/TTP revocation lists, right? |
Correct, providing the user community is large enough. It each issuer only has a couple of users, and the dozen issuers issue very different types of credential, then it would still be possible to infer which user contacted which inspector. |
Expiry times need to be considered in context and based on privacy engineering principles. Here's a sequence that illustrates the design and use of a highly dynamic claim:
The sequence above illustrates the privacy engineering considerations around verifiable claims. Privacy is enhanced when:
|
@agropper This is useful, but we need to focus on item number 3 in your list, along with bullet item 2 and 3 in the list that is bulleted. In short, we need 2-3 paragraphs only talking about highly dynamic claims and when it's a good idea to use them. We may not want to explain a full use case, as you've done above. Can you take what you've written above and write something that is more of the form here: #6 (comment) |
Highly dynamic information is subject to either short expiry or revocation lists. To avoid traffic analysis that would reveal to the issuer when or how a claim is being used, the issuer’s API could allow the subject to request the expiry time, within whatever parameters the issuer supports. Alternatively, the issuer could support a revocation mechanism that does not leak information when the revocation list is checked by an inspector. For example, if an insurance company or employer benefits manager system offers an API for a prescription rebate coupon to a subject, the subject may not want that issuer to know which pharmacy dispensed the prescription and at what time. The coupon revocation list would be maintained by the prescriber who could also aggregate rebate payments to avoid analysis of coupon use by the issuer. In another example, the subject might not want the prescriber to know if a rebate coupon was used at the pharmacy as inspector. In that case, the prescription claim issued by the prescriber would be presented together with a separate rebate claim issued by the benefits manager. The rebate claim would have a short expiry time and the decision to use a rebate or not would be entirely with the subject who might prefer to pay cash to avoid leakage of insurance information to the prescriber. |
The specification should note that validity time periods should be shorter for highly dynamic information. We should also mention that shorter expiry periods may result in less privacy due to frequency of issuance/use.
The text was updated successfully, but these errors were encountered: