In our paper “A Relationship Layer for the Web“, we defined a “contextual identity asset” as a package containing two kinds of information:
- Identity information about an individual
- Relationship Context Metadata
Relationship context metadata explicitly describes the relationship from which the identity information was obtained and the constraints imposed by the participants in that relationship on the use and disclosure of the information.
The idea behind using relationship context metadata is that it puts personally identifiable information “in context”; in the paper we described this process as creating a “contextual identity assets”. Our theory is that putting information into contextual identity assets does two important things:
- Makes it easier for those receiving the information to treat it properly (because recipients can just look at the metadata to see what the rules are)
- Makes it riskier for those receiving the information to misuse it (because anyone can just look at the metadata and see if the rules are being broken)
So, for example, imagine that instead of an identity provider passing this little chunk of raw identity information to a relying party
- Bob’s credit card number is 555-00-1212
the provider passes the following contextual identity asset to a relying party:
- This individual’s name is Bob and his credit card number is 555-00-1212
- This information has been provided in the context of relationship (services contract #42 between InterMedProvider and RelPart, Inc.); under the terms of that contract the information in part 1 may be used to authorize Bob’s payment for the current transaction, but the information may not be stored, displayed on a screen, printed, or transmitted to any third party.
The contextual identity asset in a sense protects itself. Unlike the chunk of raw data above, which conveys no information about the sensitivity of the information it contains or the rules for processing the information, the contextual identity asset is self-explanatory. It states which relationship will be damaged if the information is misused (the one between InterMedProvider and RelPart), and it also describes what uses are proper and what uses are improper. Recipients of this asset can understand their obligations to protect it, and they can understand what damage will be done by a failure to meet those obligations.
And, importantly, the contextual identity asset is meaningful not just to the technology infrastructure, but also in the “social layer” above the technology infrastructure. Humans can look at the metadata and decide whether they’re about to do something wrong – or whether they have received the information as a result of someone else already having done something wrong.
We think relationship context metadata is the way forward in privacy protection; we think private information will never be well-protected until it’s easy to tell what the rules are and whether they have been broken.
We’re doing research about existing uses of relationship context metadata, about projects underway to create and use relationship context metadata, and about the nuts and bolts of what relationship context metadata should look like, how it should be attached to private data, and what policies should be defined surrounding contextual identity assets.
If you use relationship context metadata today, or if you have or know about a project to define and use it, we’d love to talk to you as part of our research . Get in touch. Here’s how:
- On Twitter
- Email: ian dot glazer ~at~ gartner.com
Read Complimentary Relevant Research
Predicts 2017: Artificial Intelligence
Artificial intelligence is changing the way in which organizations innovate and communicate their processes, products and services. Practical...
View Relevant Webinars
The Education CIO Challenge: IT Is a Team Sport
This video will outline key Education CIO challenges and recommendations based on business and technology trends in education as well...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.