EIC 2012 Keynote: The Future of Attribute-based Credentials and Partial Identities for a more Privacy Friendly Internet

Glad to introduce our second presenter this morning, who is the professor? Dr.

Kai Berg, who has the Deutche telecom chair of mobile business, multilateral security at getter university in Frankfurt. Look forward very much to your okay. Remarks.

Thank you, sir. And I'll give you a shout about five minutes before day. Thanks a lot. So good morning. Thanks a lot for the invitation. Thanks a lot for the friendly introduction. I know cold EIC is an great conference because it's willing to take whisks and to do innovative things.

And, and let's say to take the risk to come at nine o'clock in the morning, and I'm happy that you're all here to come at nine o'clock in the morning to listen to a German professor is really a risk and know your risk of falling asleep. I will try to do my best to avoid that, but I appreciate already now that you are willing to take that risk. And this presentation is about in general, the future of Azure based credentials, such a complicated word already in the morning, and then partial IDs a little bit easier.

And for our privacy friendly internet and applications, it's the background of it is obviously, as you can see on this picture, the European union sponsored and, and help project ABC for trust and the idea of this presentation. Again, you see you're dealing with a German professor here, you have a structure, and that is about to discuss a few things on, on privacy problems and identity management.

Inance first, basically those and issues and problems that we consider most important when we designed and ABC for ABC for trust, I will then given short introduction on what actually we mean by a based credentials and which technologies and are behind that. And then I will introduce a bit further into the project, into the trials that we have in the project, which are an application cases from a social network in a school in Sweden and in teaching and lecture evaluation of a university in Greece. I will tell a few words about the architecture if there's still time for that one.

And, and then I will try to put ABC for trust a bit into perspective. After that, again, you're dealing with the German professor, you'll have to deal with conclusions and outlooks. So let's start with the privacy problems that we consider most important in the area of identity management and assurance. And let's start some 2000 years back and for some very principle and basic description of an identity management that maybe you have seen were here in the federal state of German is also is sending the current Pope to Rome.

So, and looking for Bible quote, assault, maybe maybe appropriate, this is in desire 43 1. And what you see there is one of these description of identity management, which has two major paradigm, two major paradigms here, and fear, not that is basically, and for I've redeemed you, that is the one major paradigm, because it basically says identity management elevates you to something great and something good, and you will get something more than you would get otherwise.

And then you have the other major paradigm that comes the second line and that as I've called you by name, so I'm deciding who you actually gonna be named with and you are mine. So basically I own you. I have the control over you. I've brought it in a few languages. I apologize for anybody who doesn't find their home language here. I'm happy to take more translations of this quote, but these two paradigm elements maybe, and maybe of interest, and we're going to find them back when we see some projects and some issues on these things.

So 2000 years further, this is an not so untypical architecture that you probably have seen very often in identity management and architectures was basically three and three major elements in there. You find some kind of an user let's, hopefully we have some users doing, dealing with all of this. You find an identity service provider and you find a relying party. And the typical situation that you have is a user wants something that you find there in step one, request an access.

Then the relying party says, well, on the circumstances, I'm going to give you access, but you have to bring something to me. And that could be a token. And that a token that token may be, need to be certified in some ways. So the user has to go to this identity service provider and gets a token and from the produces a token and delivers it to the relying party and hopefully can get access then.

And quite a few of the things are depending on the trust relationship between the relying party and the identity service provider on the question is can the relying party actually put trust into the token? And this is also where we often, the privacy problems are going to start. And one of the issues is in identity management, then what we can call an over-identification.

And because very often the relying party is into wanting to see quite a few things in this token that it receives and values of the tokens and that maybe telling much more than actually is needed and therefore learning much more about the user identity one could do. And one could do better things here. For example, let's assume, and we have an, a relying party who looks after a Porwal, which has content that people should only look at after they're 16 years old.

And usually what the and relying party is asking for, because it's a classic situations that you have, they're asking for both of date certificate or something like that, so that they can calculate the age of the user themselves. This actually would not be needed if it would have certificates that the user could deal with and could say, okay, this policy is over 16, okay. I have a certificate of my birth of date. If it could, we calculate that certificate into something which says yes, and the user is over 16, and that would be enough.

And then the date of birth, which for example, the precise date of birth, which is sometimes quite sensitive, would not need to be given out because just the certificate over 16 would be enough. In many cases these days, you have to go back to the identity service provider to get one very often. You don't even have the provision for that. So some more flexibility for the users to say this piece of my identities, this piece of my credentials that I would need to deliver, that would be better to have.

The other element is very often these kind of very often these kind of requests let's look back again at them, come and ask for too much, or the credentials are in a shape that too much and actually is delivered in terms of additional information that leads to some fundamental problems that actually is also being discussed and standardization. This is a slide that has an influenced the bits of discussion of the new standard 24, 7 60 on identity management from and from ISO, which basically says we have actually two different types of identities, two different ways, how to deal with identity.

And you all know most of that. So can be very short on that slide, but you see what you see here on the left side and is the organizational view of identity and identity management basically saying we'd like to reun and to unify and to combine identities as much as possible because in an enterprise setting, this is useful. Then you can make quick decisions and you can understand with whom you're confronted sometimes also in customer relationship management and you like that.

However, if you look at individuals and we've seen it before, and some of the presentations today and yesterday, people say we have different spheres of life. And for that, we have different identities.

I mean, I could ask you how many of you have an, how many of you have an eBay account? Let's see this early in the morning. Okay. Some people are moving and listening.

So how, for how many of you and for this eBay account and people can see what your normal email address is or what your normal name is. So for how many of you have not a pseudonym as an eBay account, but a real email account, which gives you a real name or something that people can identify you in elsewhere in life. One over there two, see, so that's about 10 to 20%, and that's a typical situation because most people have an eBay account, which is different. And if you ask them very often, you get the answer.

I really don't would like to discuss on Monday morning in the office, what I was bidding for successfully or not successfully on the weekend. So these different spheres of life are actually an important, and this taking these different spheres of life with different attributes into perspective is important for people also. So actually what one would need is partial identities here. You see in Alice, I thought I should have some Alice in this talk. So at least if there's no cryptos, there's a little bit of Alice and Bob.

So you see Alice and her boyfriend, Bob, and you see some other spheres of Alice's life. And all of them life was the insurance life is shopping. Life is work. Life is government. These are different spheres of life and they have actually different spheres of identity. And so actually also different identities management actually is needed. And that we don't have very often in part of the part of the systems, the other issue, and that we very often have in the area of identity issue. And if we're trying to address is the calling home problem.

You find that very much on the left side of the pictures that you have here, and that's basically, and that the identity service provider, and usually learns quite a bit about the relying party while the token request, because very often the token request from the relying party is actually is identified by the relying party as the identifying service provider, of course learns about the relation between the user and the relying party. And of course it learns about the time of access attributes and, and all of that.

Again, the user is giving quite a bit of information to the identity service provider, where we often, especially when these credentials are, let's say one time short lift credentials, because it means, oh, this is interesting. The user wants to go to a website where people, where people need to be identified by the following on a website where there is content for, for people over 16 or whatever. This is an is an issue. And we can look at it a bit more general. If you say in principle, very often, what we have in these kind of identity settings is a relation of, for elements.

We have the requester or user or whatever. On the left side, we have the relying party on the right side, we have this issuance token provider. So then the last slide I call identity service provider. Sometimes it's called credential provider. You find lots of names for all of this in the different protocols. And somewhere in the middle, you have the issue in token, and that can be important or sometimes also called password credential, whatever. There are some usually quite some complex relations between these four and entities, depending on which protocol you have.

So I'm not sure whether there's any protocols that has exact easy relations that you find on these pictures. But of course, in looking at the different relations is something that you need to do for protocol per protocol. If we would do it in detail here, we would have another two hours talking.

What you, where we often have is when the identity provider is actually called identity provider, which is a strange name in itself. Anyway, as we know, I mean, it's about services about identities. It's not about providing identities in many cases, except in a few that you sign.

See, for example, here and Zen, the point is basically that's a token, the Shoeman tokens that's the requester is getting from its identity provider, is where we often consider to be so weak that the relying party has to immediately call back and call back to the identity provider and say, Hey, is this token actually still up to date? Is this something that I want to, and that I can can believe in? Does this actually make, and does this actually make still sense? This is to some degree and a problem of the policy decision of the site, of the relying party.

And for example, we would apply that situation to the hotel here. Probably you checked into this or another hotel, maybe the hotel has asked you for your, and for your identity card and to check whether you are and to check your details and to build up a certain element of trust if in the world of this like X 500 or so, or whatever other protocol we could see here, and we would apply this checking backs that you see mark reds there.

That would mean that the hotel actually would have need to telephone the issuer of my identity card and say, Hey, Bunes I, in my case, as I'm German, Z and identity card comes from Bundai. So, Hey, Bunes I has somebody guy standing here, he wants to check into my hotel and I have this identity card that says, well until 2014, but I'm not really sure that I should trust this. And do you really, do you really think this, this is up to date and of course this would be a major effort for, for Buno stroke.

I, well, of course, in the electronic world with the technical effort we can live, but what of course, what it builds up from the privacy point of view, it builds up a single point of problems. And with the relying party, because of the relying party gets all of these contacts and all of these requests from all of the, and sorry, and it, it leaves, it leaves a major problem with the, an identity provider because the identity provider gets all of these calls and all of these requests from the relying parties. And of course they can get a perfectly nice profile on where I was traveling.

I mean, if, if we would apply this to real life, that would mean buds look arrive, would know exactly which hotels I've been traveling to all over the world or all over Europe, depending how often they ask back in the electronic world with many protocols at the moment, we accept that because we have no other, no other option, but of course, in principle, we're building up a major, major problem. We have the problem also, for example, in some of the, an implementations of stock, there are other implementations of stock and other concepts within the stock project, which are better.

And, but here we even have the, have a triple calling home problem for these kind of things. And again, you see the picture here, you see the requester and on the left side, who wants to go to, in this case, obviously from Germany, he wants to go to a Greek relying party and the request that comes with his or her German, German assu token, and the Greek relying party may not have an opportunity or from the, from the paradigm that you find in, in PEPs, in the PEPs model of stock. And doesn't really have an opportunity to build up trust, or doesn't want to build up trust into this German token.

But the idea is pretty much following the GSM roaming model to say, okay, I want to need to check at home of the credential. Whereas this credential actually is valid. And the infrastructure here is basically say, okay, the relying party is going to the, and gateway of the home country of the relying party. The gateway is going, the Greek gateway is going to the German gateway because the certificate comes from Germany and the German gateway is going to the assu and token provider. And that sometimes is called identity provider. And in a way, this is elegant.

And that's why this model is sometimes favored. It's very elegant because it doesn't, this model doesn't put any conflict and for the national identity provision schemes, because it's just sitting on top of it, like, and GS enrolling, everything that is inside the country can be dealt with inside the country, the problem, and the privacy problem with this model is, and that, and with this kind of request that you see there in these three wet and circles, the whole application context, for example, of a website that is a requester is and is asking.

So let's assume the relying party in Greece is a, is a website. And the, as we have stateless situations with websites, the whole context is coming back in the request back to the issue token provider, which basically means that in this case, the German assu token provider learns about all of the requests and all of the requests that the requester is making somewhere else in the world.

And again, it's building up this very, or could build up this very nice profile or actually very dangerous profile of all kinds of requests and that the user makes over there in the world. And all of that, because there are no tokens that the Greek relying party could trust in itself. Of course you could build the model differently, but then you would have to find a way how the Greek relying party could learn about the German or other countries, assu tokens in a way that's, couldn't be built up trust.

This is now where we are coming into the concept of based credentials, which to some degree can solve some of these issues together with some policy considerations. And, and so what do these based credentials? And sometimes we also call them privacy, ABC to have this privacy aspect lined out a bit clearer, and what do they do, basically what they can do is, or what you can do with them. You can have a certification of relevant and relevant attributes there.

And, and what you can also do is you can have the token issuance and the token presentation UN linkable from each other. So in a way, and you would consider these things as coins that are the paradigms that you can have in mind, even rather than bank notes, because bank notes have a serial number, but you have some certificates that show that show a certain provider and sorry, a certain requester has something to offer, which shows tells about him or her or her attributes.

And the user can disclose subsets of the encoded claims that I Ze, for example, let's assume somebody, some relying party would encode my whole identity card was my date of birth was my current address. And with my eye color, with my size also, and then I want to go to that website, which only allows people over an over 16 and maybe people from Germany, I could take two attributes, like I could say, okay, I'm over 16 and I'm, and I'm from Germany. You don't need to know that I'm from Frankfurt or wherever.

And, but these two attributes I can take and can respond to an request from a relying party and can say, this is what I want. And if the relying party comes up with an unanticipated request or say, well, actually we have changed this to over 17.

Again, I can calculate from my certificate and on my own and say, okay, I need something now over 17, okay. I have my birthday certified, so I can calculate something. And that claims that I'm and tells that I'm over 17 or over 21 or whatever, what is needed. If you look into the world of technology, you at this moment, you find two major approaches and technologies that can deal with these kind of things. The one thing is you proof that originally was coming from Creda and Creda was acquired by Microsoft together with an, the hub proof technology. We have heard about Kim already.

At some point in time, he was very instrumental in that one, as the other technology is edix, it's the outcome of an research project called prime and prime life was developed or IBM, both of these technologies and work slightly different in the way, how they're being, how they're being worked at on the left side of this picture, you find you proof and you see the relation between issuer user and there.

And the, and from this little wall that you see on the, on the picture, on the left side, you can see that basically between user and issuer hub proof says, we build up a wall here and we make ensure that actually a user can get credentials. And even if the issuer doesn't know exactly who the user is, and by, by using blind signatures, which is one of these earlier technologies that David sham already had been using, we can make sure that you can get such a, that a user can get such a credential.

Sometimes the let's say picture, how you can can see that is, think about presenting an envelope to somebody to stamp it. And, and you can, the person who stems the envelope together with the content, they can see that they can see that the envelope is about, let's say this party has an, an account of five euros, but not necessarily the name is shown. So basically a coin is being prepared. That's how you, let's say in a nutshell can view you proof. And Emix is a technology which came about 10 years later.

You see some of the names who were involved in involved in that one edix puts and was using zero knowledge protocols and zero knowledge proofs, and puts actually the M phases on the relation between the user and the verifiers, the user, and the, and relying party, and comes up with a model that one can say, okay, I'm going to present. I'm a user. I'm going to present you as a Verifi, some kind of credential and this credential, and will not tell you everything about me, but using zero knowledge proof, you can find all the development elements of it.

And the reliability of that is as good as anything else that you could have and as a credential. So in a way where you can see with both of these and both of these technologies, and they're relating identity much more to, let's say, a partial den, partial identity, and also putting it much more relating to the attributes that are related to an identity.

So from that point of view, we can also say ABC for trust is actually quite in line with more recent standards on identity management, which basically say identities are actually combinations of attributes and combinations of those attributes that are relevant in a certain situation. And that brings us back to this identities management situation, where you can come up with those attributes and that are relevant in your specific context. So everything wonderful, Microsoft and IBM have solved the problem for us.

Why is there still a problem and why is there still a project and why not going home and having a party? And while the reason is that these two technologies are sadly different. You already saw they come from different and they come from different and cryptographic roots, and they have a slightly different setting in how the thing is being built. They have also slightly different features. So not everything that is easy with one protocol is easy with the other one.

And if you would just put all of your, of your, in one of these baskets, some people say, especially in Europe have said, well, these are wonderful companies, but still, we would not like to have a one supplier strategy with everything from one company. And also we would not like to have a one technology strategy because maybe at some point in time, somebody comes up with a weakness in one of those technologies, because this happens with cryptographers that after 10, 15 years, sometimes they find weaknesses or weaknesses show up or whatever. So better.

Don't put all of your eggs in one basket and try to develop more technologies that go into that direction that is happening on the one side. But also if there's only two at the moment that you can may use of and try to find some common and unified architecture for all of these ABC systems to enable and the opportunity to compare the features of the technologies and to combine them on common platforms. And so to enable some kind of lock in free usage of ABC systems. So this is basically what an ABC for trust is about in the beginning.

Then the idea is to have an open reference implementation of some ABC system so that something can be there for people to use and to tried out and also to have deployments in actual production environments. Because again, these are nice and new technologies, but they're a little bit more complex. And some of the very easy and identity management systems that we have seen, and one has to see in how well does it actually fly when you want to have this minimal disclosure.

And when you want to have this provision of feedback to your community, and also the point is to see which relevant standards could be and could be applied, or how in relation to relevant standards, which are the ones that we want to and want to deal with. And partners in ABC for trust are maybe you're not surprised entities from and Microsoft and IBM among other parties.

Actually, we have an French, an entity of Microsoft, but Microsoft as a whole is backing up the whole thing. And we have a Swiss entity of IBM like IBM mutual connect. IBM is backing up the whole thing. And then you find a few other, and a few other partners like go to university in Frankfurt where I'm coming from, because we put this all together and the idea of a score, for course not to have it coordinated by one of the, and by one of the, and let's say companies who are putting in to some degree, even competing technologies here, we have Alexandra Institute from Denmark.

Who's doing lots of research in that area. And then we have RTI from Greece who are also wanting the one trial prototypes that I will disclaimer and, and explain or, and tell a bit about more in the next minutes. And we have miracle as spinoff from Alexander Institute. We have NOIA Siemens networks here from hear from Munich, and we are happy to see that this is one of parts of NOIA Siemens networks that actually is, is thriving and, and putting, putting more people into job in, even in Munich here. And from NOIA Siemens networks, we have dam start for some whiskey analysis stuff.

We have the, when I London sent on for Schutze, this is a very German name for something it's basic. These college done privacy commissioner. So say Collegetown for those of you are not in Germany. And privacy commissioner is actually one of those privacy commissioners who are most into technology of all the privacy commissioners in Germany. They have a lot of internet and internet experience. Recently. They also got a bit, a bit popular or unpopular, depending on your point of view.

And by going after Facebook and the like button implementation of Facebook, that transfer information, even to Facebook, even when you don't, Pressly like button of Facebook, Andary college term was the people who raised this issue. So I think they will make sure that this will be privacy friendly. And then we have Euro docs and, and the city of C Hamman or of C Hammond. They look after the Swedish school prototype and crypto experts and Microsoft research and development. So what is happening in the project in five minutes, what's happening in the project?

We have, we have basically this analysis of the technology. Of course, we have an architecture design technologies are being compared based on that. We have the reference implementation the testing of it and deployment and could pilot trials on the left, on the right. You find management. So we INFR for hopes that we can manage the hosting and, and you have dissemination on the right side. So this is the school trial of the Swedish school. We have the situation here as a school has an social network on its own, and they have basically two, two situations that they want to deal with.

One situation is they have discussion groups for pupils and these discussion groups for pupils and as teenagers, and would not work in a proper way. If the people would have to come under their wheel and clear names and people, teachers wouldn't simply not discuss what they want to discuss under that they don't want to have that with their teachers and other people around. So they want have pseudonyms and the school wants to make sure that you don't have 18 year old teenagers in who going after 12 year old and 12 year old people or so, or even older people.

So what's, the credential is the at actual credential that is needed is basically somebody is part of the school for certain groups, not older than 12 for other groups, at least 14, for other groups in a different time area, in a different time scale for some of the counseling services at the municipalities offering, they want to have the certificate. And the attribute is really a pupil from this in respective city and not from somewhere else. And so these are the attributes that are going to be tried out.

And of course, the challenge also is to make sure that this kind of attribute based technology is as good that pupils can deal with it. And in some situations, when the parents are involved, even parents can deal with it. Some people say it will be a harder challenge to get it parent working than to get it pupil working. I leave that to your own assessment with you and your, and you and your children see, as in trial is about course waiting. It comes from a deep distrust against professors. So I don't like the example, but still we have it.

And, and the distrust against professors is that if students would say, and given honest and honest account of revelation and ation of a lecture that they had, or of a course that they had, the professors would go after the students, if the account is negative. And that's what in general students fear because professors are considered to be bad.

And so we're covering that and covering that point, of course, because honest and accounts of causes should be like that, and that they're anonymous, but at the same time, the accounts should only be from students who really went into the lecture and from students who took the examination, you don't need to pass the examination, but you should take the examination after that. You can evaluate the whole cause. So these are the kind of attributes that need to be accounted and collected over the term.

And then when you do the course evaluation as a student, then you present all of your attribute credentials, and then you can actually say, okay, now I can give the revelation of the, of the course. We have interesting issues here and early morning issues, of course, and the students will get smart cards. The students have to collect the credentials for each and every lecture. And then they come all at the same minute with a smart card into the lecture room. So how do we get them these credentials quick enough, these are some of the practical things that we have.

So I think I have one or two minutes for the architecture left architecture is basically about entities and interactions. Some high level features, component APIs, and some XML specifications of data formats. And again, this is something that you probably want to prefer to read later anyway, because it's nine o'clock in the morning. These are our players. We have seen these players before. One of the important one is the inspector who inspects tokens on behalf of the fire, but that does not mean that he goes back to the, an issuer, but he can do that. And on his own.

So we don't have this issuer user relationship, and we have a number of presentation policies and per presentation tokens. And I promise that I would show some XML in here. So you'll see some XML if even for only some only some seconds here, but we can discuss that also later, you can basically see if you could see it from the XML. And that's a, is a token and defining somebody that somebody is over a team. This is the high level view of the, of the whole architecture between user.

And basically you see that is this kind of ABC engine, which is managing all of these credentials and all of these tokens, putting this into perspective and means basically, what are we doing here? We're trying to consider the views of the respective of the respective and parties and stakeholders. And we are trying to integrate this into a value chain of a business business processes and applications, and then conclusions and outlook are obviously with all of these services we're coming ever closer to and to people.

And so if you want to have privacy friendly internet with regard to these credential and identity management, you need see partial identities and the respective identifiers, you need minimum disclosure and you need attribute credentials for that. And you also need assurance tokens, which are strong enough that people can actually evaluate them. And if you like to see more, I'm happy to discuss it with you at any point in time. You and you, like you find also some of the heritage of the project and some of these other websites of earlier approaches ABC that ABC for trust is proud to base upon.

And with that, I think I have eaten up my 30 minutes and should make sure that I'm not.