ceci n'est pas un bob: the meta-identity system

ceci n'est pas un bob: the meta-identity system ceci n'est pas un bob musings on security, identity, privacy, and risk. and nice red uniforms. 12 july 2006 the meta-identity system let’s start with a question: “in the identity metasystem, how can identity providers exist?” it seems simple in principle; someone sets up an identity provider server which has a web services security token service (sts) and a policy engine. the server invites “subjects” to create profiles (lists of identity attributes) and then creates signed tokens asserting those profiles for consumption by relying parties. all this is easy to do. the paradox of the identity provider what’s hard is: paying for the identity provider server and the service it provides. convincing relying parties that they should rely on information provided by a third party (the identity provider) rather than maintaining identity attribute information themselves. assigning liability when a relying party asserts that a claimed identity attribute is incorrect. assigning liability when a subject claims that the wrong identity attribute claim was released to a relying party. making subjects whole when a security failure “leaks” subject identity attributes directly from the identity provider. assigning liability and making subjects whole when a security failure “leaks” subject identity attributes from a relying party. there’s a vicious circle here. relying parties won’t want to outsource identification of their transaction partners unless they can feel sure that the identity provider’s information is better than their own, or unless they can be indemnified against losses arising from mis-identification. identity providers, therefore, have to spend a lot of money on data verification, or liability insurance, or both. but to spend a lot of money, identity providers need to make a lot of money. this means that either their fees or their transaction volumes need to be very high. to generate high fees and high transaction volumes, identity providers need to have a valuable asset. and (here’s the rub) if identity providers provide their subjects’ identity attributes to relying parties, they don’t have an asset - because they’re giving it away to their customers. the potemkin village parenthetically, by giving identity attributes to relying parties, identity providers turn the identity metasystem into a kind of potemkin village - a false front hiding emptiness and weakness. the identity metasystem's subjects rely on the identity provider to safeguard their private information, but the identity provider can’t safeguard information which is sitting in relying party systems. unless the relying party's systems change, the implementation of the identity metasystem does nothing to reduce the total privacy risk of the environment it’s introduced into - though it may increase relying parties’ liabilities for that risk, because the identity provider’s contracts may create liabilities for relying parties who mishandle the information they provide. the meta-identity system if this seems gloomy, there’s good news. the technical infrastructure of the identity metasystem contains the seed of a solution to both problems (“how does the identity provider make money?” and “how do we avoid building a potemkin village?”). that seed is metadata. in order to build an asset, the identity provider has to stop giving its crown jewels - identity data - to its customers. it can do this simply by changing what it puts into the claims it hands out to relying parties. instead of answering a relying party’s query “how old is bob?” with the claim “bob is 45”, it can answer “how old is bob?” with the claim “bob is over 18”. instead of answering the query “is bob a good credit risk?” with the claim “bob’s credit history is (fifty-page report goes here)”, it can answer “is bob a good credit risk?” with the claim “97% of people with credit histories similar to bob’s repaid loans of under $200,000 on time.” claims like these contain metadata rather than data. from the point of view of the identity provider, identity metadata has two big advantages over identity data. the first advantage is that using identity metadata in claims allows the identity provider to provide a service to its customers without handing over its core asset - and in fact using identity metadata allows the identity provider to build the value of its asset by developing expertise in analyzing raw identity data and transforming it into more and more accurate and useful metadata. the second advantage of using metadata instead of data is that it allows the identity provider to provide a service to relying parties while minimizing the disclosure of specific personal information to those parties - thereby reducing privacy risks to subjects. once the identity provider gets out of the business of providing raw identity data, of course, it no longer makes sense to call it an “identity provider”; calling it an “identity metadata provider” sounds hopelessly geeky, though, so i propose instead to call it an “identity oracle”, since what it’s really doing is answering questions about an identity. as a technical community and as a society, we can realize a lot of benefits by eliminating identity providers. instead of building an identity metasystem with identity providers, we should build a meta-identity system with identity oracles. the technical infrastructure of the identity metasystem doesn’t need to be changed - all that needs to change is what we put in the claims and the way we think about the system. i gave a talk about this at the recent burton group catalyst conference. the talk includes a lot of material i haven’t discussed here; if you’re interested in listening to the talk, the burton group has kindly posted it in podcast form here, along with the accompanying slides. posted by bob blakley at 6:04 pm    4 comments: bob blakley said... i should note that eric norlin and aldo castaneda have already commented on my talk.eric asks if google is an example of the identity oracle. i think the answer is "yes and no". in one sense - in that it indexes data about me and makes the index publicly availble to the whole world - it's exactly the opposite of the identity oracle. but in another sense - a sense aldo describes in his entry - google is an identity oracle, because it collects information about me with my consent (or at least tacit cooperation) and then uses this to do indirect things like figure out which advertisers should be putting things in front of my eyeballs. when google puts ads beside my gmail messages, it's essentially telling advertisers "bob's your kind of guy" - but without showing them the text of the email on the basis of which this determination was made.aldo argues with me on two counts.first he claims that i've oversimplified the internal logic of corporations by saying that they don't care about your privacy. i did say in the talk that corporations can be made to act as if they care about your privacy through the imposition of regulations and financial incentives, and i believe (though i didn't say it in so many words in the talk) that regardless of fiduciary responsibilities and obligations of directors, corporations "value" profit more than they "value" your privacy, and that (not being real people) they "care about" neither.aldo's second objection is that my glasses are too rosy when i suggest that using metadata instead of data will reduce identity disclosures. here he uses google as an example, and notes that google protects privacy against the us government but not against the chinese government (i can't help but note here that this contradicts his first objection!), and then he goes on to say that google is leveraging cheap bandwidth in an attempt to become the identity oracle. - but this supports my point rather than contradicting it! july 12, 2006 9:25 pm   superpat said... i've participated in discussions along these lines in the past... presumably, the requestor gets to phrase its question "is the user over 18"? if so, then the requestor can start to play 20 questions to narrow down the range of values: "is the user under 65", "is the user over 41" etc.so you have to have rules about how many times you can ask about a given attribute, right? july 28, 2006 5:56 pm   frank yeh said... the analogy to the identity oracle (i hate that term, btw it uses a major it company's name!!!) would be in the way that passwords are one-way hashed. you are able to use the values effectively without being able to discern the actual real data. this is goodness.however, i haven't seen anything that says that the identity provider (cubbyholer? demographer? profiler? anything but oracle!!!) has an implied responsibility to verify that the identities and identity attributes presented are in fact accurate. anyone can register with a google or a yahoo id and they pretty much enter whatever they want for their identity attributes.so in order for the meta-identity service provider to have somthing of value, not only does the identity data and the access to it from all relying parties need to respect the privacy of this data, but the data must be validated by someone when entered.as with most things, the technical challenge is not huge but the social aspects of doing something like this are enormous. verisign has the registration authority, which essentially serves as a validation point for data before it enters the system. the meta-identity provider should probably have something similar. without it, we are faced with a classic garbage in garbage out scenario. august 01, 2006 9:27 pm   tootallsid said... i have hatched a simple scheme to use infocards for e-commerce that is compatible with visa's 3-d secure.the beauty of it, bob, is that it implements a payment oracle.in a nutshell, the merchant sends the transaction details down in the claims. the consumer picks a payment infocard. the issuer looks at the transaction details and decides whether to authorize the transaction. if so, the issuer returns a security token along with a pseudo account number, tied to this transaction, but not to the consumer. the merchant uses the account number to route the transaction through the backend payment network along with the security token.in other words, the merchant asks the consumer to prove that they are good for money. the issuer oracle returns an answer: yes they are and send this token to this account number, and you'll get paid.the only identity info that leaks is the name of the issuer that the consumer is using to pay with. no account number, no billing address, no email address, no cvv, no nothing. the pseudo card number has no meaning in meatspace or cyberspace, outside this particular transaction.so infocard and identiy oracle are compatible, at least for payments.bob, send a message to me and i'll send you a copy. november 01, 2006 3:10 pm   post a comment << home about me name: bob blakley location: austin, texas, united states i work for the burton group, but the postings on this blog reflect only my personal views; they do not necessarily represent the views, positions, strategies or opinions of the burton group or its management. view my complete profile previous posts memorial day auto-exposure how i take a picture 1: take responsibility within this decade sorry, jim, reputation is a story words of wisdom from sam hughes reed's 2006 calendar on the absurdity of "owning one's identity" international dadaism month 1   rangefinder blog/site ringring owner: shards of photography site: shards of photography

ceci n'est pas un bob: the meta-identity system  Prcdent 180  Prcdent 179  Prcdent 178  Prcdent 177  Prcdent 176  Prcdent 175  Prcdent 174  Prcdent 173  Prcdent 172  Prcdent 171  Prcdent 170  Prcdent 169  Prcdent 168  Prcdent 167  Prcdent 166  Prcdent 165  Prcdent 164  Prcdent 163  Prcdent 162  Prcdent 161  Prcdent 160  Prcdent 159  Prcdent 158  Prcdent 157  Prcdent 156  Prcdent 155  Prcdent 154  Prcdent 153  Prcdent 152  Prcdent 151  Suivant 182  Suivant 183  Suivant 184  Suivant 185  Suivant 186  Suivant 187  Suivant 188  Suivant 189  Suivant 190  Suivant 191  Suivant 192  Suivant 193  Suivant 194  Suivant 195  Suivant 196  Suivant 197  Suivant 198  Suivant 199  Suivant 200  Suivant 201  Suivant 202  Suivant 203  Suivant 204  Suivant 205  Suivant 206  Suivant 207  Suivant 208  Suivant 209  Suivant 210  Suivant 211