In a previous blog entry, Identity as a Rental (IDaaR), I discussed the concept of authorizing access to personal information for a temporary period. This is nothing new -- users commonly grant granular access to a subset of their data on social applications. Open standards such as OAuth and OpenID Connect easily facilitate this use case.
The larger issue is revocation of these grants. Let's assume we have an IDaaR-aware application that connects the calendars of two people meeting for lunch from 12pm to 1:30pm. The 'lunch meeting' profile for the IDaaR app is configured to share the pertinent attributes for such a meeting: GPS location, full name, company information, work email, cell phone, and dietary restrictions.
These attributes do not present a revocation problem. Some are ephemeral (GPS access). Some are easy to obfuscate (send a one-time value for email and phone). The remaining attributes are unimportant to obfuscate (since you WANT the client to remember your full name & company information) or else you don't likely care if they remember your dietary restrictions in the future.
However, in other profiles you may want to pass sensitive/personal information that is difficult or impossible to mask with an opaque value (biometrics, home address, favorite pet's name, or your photo). An application can be programmed to forget sensitive/unmasked attributes. A human being cannot unsee such information.
Rather than pass the actual attributes, an IDaaR Attribute Server could be employed to validate the data. Instead of sharing the actual fingerprint, your IDaaR-aware app could share a token to be used in a validation request. The app seeking to validate the fingerprint would submit this ticket along with a hash of the biometric data. This use case would require connectivity to validate the request, which may not be available to the client if you are at a remote concert venue or otherwise out-of-band. Not to mention the triviality of reverse-engineering the hash if you have stored the original data which created the hash.
The issue of trust arises as well. Each application will warehouse the data differently. Will it store borrowed attributes in memory? Local persistent storage? How will the two apps validate the policies and trustworthiness of each other?
These questions/limitations would limit the types of attributes apps could share with each other, as well as the use cases where this type of temporary sharing of attributes would be effective.
Jeff Rosenberg is a technical instructor in the Client Services group at Ping Identity.