agropper
commented
8 years ago It sounds like a feature but, even as a 'professional' privacy advocate, I'm at a loss to think of a real-world use-case.
Adrian
On Thu, May 26, 2016 at 3:38 PM, Justin Richer notifications@github.com wrote:
In the current protocol, particularly with regard to pushed claims, the AS is going to have some set of policies defined by claims that are required to fulfill those policies. In order to help the client know what to do with a need_info response, the AS is allowed to tell the client some information about what claims are required in the way of telling the client the issuers and claim names. The client doesn't get to find out what claim values are required to fulfill any policies, as this would leak private information about not only Alice but also anyone Alice has created a policy for. However, since the client doesn't know what claim values are required, a well-intentioned client could erroneously present a bunch of claims from the RqP that don't have any chance of fitting the policy but would leak information about the RqP.
A potential alternative would be for the AS to hash the claim values and return the hashes with the claim names. This would allow the client to perform the same hash against any values that it knows about and figure out if it's worth submitting these claims for this policy or not, preventing unnecessary leaks. The hash would ideally be calculated using a randomized salt, such as the current ticket value for the transaction. (See #205 https://github.com/KantaraInitiative/wg-uma/issues/205 and #239 https://github.com/KantaraInitiative/wg-uma/issues/239 for information about proper rotation of tickets at each step.)
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/254
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
xmlgrrl
jricher
In the current protocol, particularly with regard to pushed claims, the AS is going to have some set of policies defined by claims that are required to fulfill those policies. In order to help the client know what to do with a
need_inforesponse, the AS is allowed to tell the client some information about what claims are required in the way of telling the client the issuers and claim names. The client doesn't get to find out what claim values are required to fulfill any policies, as this would leak private information about not only Alice but also anyone Alice has created a policy for. However, since the client doesn't know what claim values are required, a well-intentioned client could erroneously present a bunch of claims from the RqP that don't have any chance of fitting the policy but would leak information about the RqP.A potential alternative would be for the AS to hash the claim values and return the hashes with the claim names. This would allow the client to perform the same hash against any values that it knows about and figure out if it's worth submitting these claims for this policy or not, preventing unnecessary leaks. The hash would ideally be calculated using a randomized salt, such as the current ticket value for the transaction. (See #205 and #239 for information about proper rotation of tickets at each step.)