Manu Sporny: Hi Mike, thanks for joining us today. When we run these calls we minute and record them and we'll be reporting the result to the W3C and the VCTF, if you don't want audio recording just let us know we can turn that off if you're not ok. ✪

Mike Schwartz: No, that's fine. ✪

Manu Sporny: To start off, it would be good if you could give us a quick introduction about who you are and what you do. ✪

Manu Sporny: After that we can go through the agenda we have. ✪

Manu Sporny: Problem statement, system design, stakeholder benefits, etc. We just want to get your thoughts on this, this is just a proposed agenda, if you want to deviate or focus elsewhere that's great, talk about anything you think is interesting in this area. ✪

Mike Schwartz: Sure. I'm the founder and CEO and Gluu. We are an open source software developer and we produce an identity provider product called a Gluu server to authenticate individuals. It integrates a number of open source components included Shibboleth SAML, we also have Ox and an Ox-based OpenID connect provider. We have a SAML proxy and LDAP server and it's really three different components for authenticating people with different mechanisms with APIs to leverage that. Over the years I've been active in implementing standards like SAML and OPenID Connect and Oauth 2 profiles, I'm currently chair of a Kanara group -- a WG that is trying to assign a new way for a central authority to vet organizations and the federation identity services they provide to drive down costs and technical and legal barriers to interdomain collaboration. ✪

Mike Schwartz: Before starting Gluu I was an identity management consulting for more than a decade and interested in giving users more control over their information and I have some thoughts in this area I'd be happy to share. ✪

Manu Sporny: I'm sure they will be helpful especially given your experience in this area. All of the techs you mentioned have come up so getting someone with direct experience is really helpful and we want to learn a lot from you. Thank you for being here. ✪

Manu Sporny: We'd like to start with the problem statement to set the stage for what we're trying to work on. The reason this series of interviews is happening is because we're trying to make sure we're not solving something that's already solved and that it's not a problem so sticky we'll fail. We are talking with people like Christopher Allen, Dick Hardt, Brad Hill, Drummond Reed. ✪

Manu Sporny: We're getting all these peoples' input to determine if the problem statement is defined properly. We want to hear if any of the initiatives you're involved in would help solve the problem, etc. ✪

Manu Sporny: http://w3c.github.io/vctf/#problem ✪

Manu Sporny: We're saying that architectures used by SAML and Open ID work that has happened before -- don't solve the problem: which is sharing claims via the Web in a user-centric architecture. Christopher Allen called this "self-sovereign" where people are in control of these credentials and decide how they are shared. So for example, an issuer gives a credential to a credential holder and that holder, a person, goes to another place on the Web and provides it to some other requesting site. ✪

Mike Schwartz: Let's unpack this before going further. ✪

Mike Schwartz: You should talk to a law professor at the University of Washington and he's got a great framework for understanding this area. He breaks privacy into a triangle. Each of the points are: level of assurance, level of protection, and level of control. All three of these ... when you read regulations about privacy you can tag them with one/each of these three. SOmetimes they get stuck together and that makes it difficult to discuss these things. ✪

Mike Schwartz: Level of assurance is used by a website that needs assurance that the other person on the other end really is the person it thinks it is. You hear that talked about the most, because NIST has defined 4 levels and you hear it in the industry. The gov't really wants to know it's you when conducting business. I think a lot of people undrestand it. I think level of protection and control that people don't understand. ✪

Mike Schwartz: Level of protection is about how the data is protected when stored. When the gov't gets the data how is it protected? Data can get stolen like Dept of [missed]. They were very interested in making sure it was you but less concerned about the rules for protecting the data. Those are the two parts we have the most legislation about. In HIPAA you'll see that healthcare providers have to store data encrypted, etc. LLP legislation in a lot of different places. The last piece of the triangle that is generally forgotten is control. That is the right of the individual to control the data. Do I have the right to delete my data, correct my data, determining who shares my data. We have very poor legislation and protections here. We are starting to get some better ones in certain states and countries. It's generally the last one thought about because there was more business interest in the first two legs of the triangle. ✪

Mike Schwartz: Before we get any further, a really important question you have to consider is: "Is personal data property? Or something else?" ✪

Mike Schwartz: These are questions I highly recommend you raise with Scott David. ✪

Mike Schwartz: They are fundamental questions that can change your perspective on the whole problem. Let's take a hospital use case. They are required to keep records for seven years. Do you have a right as a patient to go to a doctor and ask them to delete it? No you don't. It becomes very sticky. If you look at data as a property right you run into trouble. ✪

Manu Sporny: Let me clarify that really quickly. We're not looking at the data in that way. It's important to raise those questions, but the core of the problem statement is about being able to store certain types of data, specifically, verifiable claims, driver's license, US passport, things of that nature, these claims are things other orgs give you to hold on to. ✪

Manu Sporny: We are saying that some orgs want to give you a credential and have you hold it and then give it to someone else. It's much closer to a wallet so you stick those things in your wallet and we're trying to bring that to the Web, to the digital world. ✪

Mike Schwartz: When I see "user-centric" ...what I hear is that you want to define an architecture that facilitates user control for the data. ✪

Manu Sporny: Systems exist today like facebook, twitter, etc. This is like OpenID connect, relying party and identity provider, and your identity is tightly coupled to the service. We're calling that service centric, and there's another model and there is no tight-coupling between the issuer and the identity provider and those are split into two parts and the credential holder can decide where to store their claims. ✪

Mike Schwartz: Just to be clear, a credential is something that enables it to prove it's you. A private key, a password, but attributes would be pieces of informations about you. ✪

Manu Sporny: When we say credential we mean the dictionary definition which is a set of attributes about an entity. ✪

Mike Schwartz: You are thinking of like a driver's license with attributes on it and calling it a credential. ✪

Mike Schwartz: That may be very confusing for identity people. ✪

Manu Sporny: Ok, when we say "credential" we mean attributes and verifiable claims. ✪

Mike Schwartz: It's a useful distinction because you don't need your credentials in all the places where your attributes are. If you take your degree for example, your university has that but doesn't have your password or private key. ✪

Mike Schwartz: Your user claims are, by definition, are distributed because there are different authorities that have those claims. ✪

Mike Schwartz: I have an issue with your definition of Open ID Connect ... it's a technicality who provides the attributes, the identity always exists in the context of a domain. I tell you that self-asserted information is not useful, ... it's not useful for transacting business for the most part. You always want to know the identity attributes in the context of a level of assurance which can only be provided in the context of a domain. Whether they provide it directly or sign it and put it on a smart card and deliver it differently is irrelevant. ✪

Mike Schwartz: That's what's important... I like the idea of user centric if it means user control, but if it means information outside of the context of domain. ✪

Manu Sporny: When we say user centric we do mean control and the user is in control of where those attributes are stored and sent. ✪

Manu Sporny: And clearly you do need a "domain" for where/how those are trusted. ✪

Manu Sporny: Does that help clarify? ✪

Mike Schwartz: Yes. ✪

Mike Schwartz: The identity information is in the context of a domain. If the question is just technically, what is the best transport and storage mechanism for the attributes, is there an opportunity for a new identity storage scheme, the answer is yes. OpenID Connect and SAML are really specific, not a panacea for identity. They are just solving single-sign-on. And you want to rely on one identity provider for that. ✪

Mike Schwartz: What they are doing is fine and they are heavily reliant on Web technology and redirecting the user, it is what it is, I don't think anyone has any delusions about it being the last identity solution we'll have but it's just for SSO and there are a lot of gaps and new techs happening. ✪

Mike Schwartz: If you look at some of the drivers for what came about ... if you look at the trust model behind OpenID Connect and SAML and you see more interesting opportunities for trust. Trust is what has been difficult to achieve. The internet is the most decentralized and untrusted network out there -- and what the challenge has been is how we establish trust with a certain domain. OpenID Connect offers a trust model where basically it's very decentralized. I'm going to connect with TLS to an identity provider ... it's a very 1:1 relationship, I trust IdP 1, 2, an 3. You can't find out which ones you trust, no trust management there, really hard question. In SAML you have multiparty -- you have InCommon. That's a good example of a central trust model where the InCommon organization, which is a non-profit, vets the IdPs in this federation and they publish the meta data in one place. ✪

Mike Schwartz: This is slightly more efficient trust model because here are the 549 federations and 242 websites I trust. If there are 10 million of these it wouldn't scale. ✪

Mike Schwartz: In the trust model maybe you're defining where there's a more distributed storage of user information that could be verified ... there is an opportunity for that. It's new area. It would take some work in looking in some of the barriers in some of these other technologies especially crypto barriers. What was Oauth 1 not successful and Oauth 2 was? One of them was signing was a barrier to adoption. If the distributed solution is based on signing is one of the questions. We're just building a PKI and I don't think we want to do that. ✪

Manu Sporny: Let me try and boil down the trust architecture we're looking at and see if you've got high-level thoughts on it. ✪

Manu Sporny: We're looking at islands of trust on the Web and the internet. We believe we can hit Web scale with the work in the Credentials CG (just an experiment, not directly part of VCTF), there would, for example, be consumers of verifiable attributes. As an example, an online wine store wants to be able to sell to people over age 21, etc. They want to depend on the state government via a claim that says "over age 21". The consumer of the credential is going to say "We accept credentials from all 50 states". When you go to your storage to get a credential it will know whether or not you can meet that request. The relationship isn't between the wine store and IdPs it's with them and all 50 states. The EU would solve it in another way, and healthcare problems would be solved differently, etc. So on. ✪

Mike Schwartz: Let's say what if we had a digital driver's license. To be honest we're working on this right now in the state gov't area. And you're right you don't want to tell the liquor store your name and address just that you're over 21. Two paths: present an identifier to the store and they make their connection to the state and (Open ID Connect model) and they ask about the user's age. And the claims might be signed or not be signed but you've got a clear connection to the state via TLS and you can trust them. ✪

Manu Sporny: Provided you have a relationship with the IdP. ✪

Mike Schwartz: A preexisting relationship it can be automated as well. I don't have to get a client ID. Open ID Connect does that. But there's a requirement for a connection, if my internet access goes down or for some reason the IdP goes down I'm out of business. ✪

Mike Schwartz: So the other way is like smart card technology and by having the root certificates I can decrypt the attributes on the card or a phone and the app just releases the minimum attributes and those are the two solutions we have today. The OpenID Connect solution ... the idea that we have a big PKI is full of problems like revocation, what if we discover a smart card was issued fraudulently and then you need revocation -- doing an SSL connection is less problematic than dealing with revocation issues. ✪

Mike Schwartz: Do you see your solution diverging from one of those two patterns? ✪

Manu Sporny: Yeah, I think so, but I don't want to go too deeply into this because we're not trying to talk about solutions, and we have some experimental solutions that deviate from those two options. It's smartcard like but it exists purely in the browser and you don't need to have a connection to the IdP and the relying party, including with the revocation problem you outline -- that connection is between the issuer and consumer -- some decentralized ledger tech and some other things there that we don't have time to get into today but we can discuss later on. ✪

Manu Sporny: Getting back to the problem statement, you're concerned about user-centric tech so we have to clarify that, our use of the word credential you feel will be confusing. We've seen that happen before and that helps underscore that. During the discussion, as far as user-centric mechanism for expressing claims and user is in control and privacy protecting so IdP doesn't track where you use these claims, do you feel that SAML, LDAP, etc. are equipped to solve that problem today? ✪

Mike Schwartz: In OpenID connect and SAML the IdP knows everywhere you went, so you don't have privacy there. You have some correlation for each website, a different subject identifier can be given out to prevent correlation of a user. If you give your gmail address to every website they can create a profile of you, then they won't be able to do that correlation. OpenID Connect supports that and SAML implementations generally support that too, Shibboleth has that. The IdP definitely knows everywhere you've been. They can sometimes use that to provide audit and security. Maybe the smartcard solutoin is more privacy protecting in that way because the issuer of the card has no idea where you use that card. I think there is a lot of work ... it's really hard to transact privately on the internet right now, it's not impossible. I'm skeptical about the ability to do that because of the network fingerprint you end up leaving when you traverse the internet. I have to admit it hasn't been my biggest concern. My biggest concern is about the universities we serve ... they want the users viewing content can do so anonymously but be identified by the university at the same time. We want to let people view uni libraries without knowing exactly who it is but that it is a student. ✪

Mike Schwartz: Private browsing doesn't really help much. ✪

Manu Sporny: So the VCTF is trying to figure out if we have consensus around particular work items -- where if we completed that stuff we would have a more successful user-centric standard for expressing/transferring claims. ✪

Mike Schwartz: Current models and protocols aren't designed to solve the problem of having multiple claims from multiple parties. One IdP makes all the claims. It's one thing for me to say I have a 4.0 another for them to say it. ✪

Mike Schwartz: One idea I had was to propose something other than OpenID Connect ... I felt like in OpenID Connect the access token ... it gives you access to the user info endpoint, you can then find out what the user's gmail address is and you can't find out anything else. You can't use that access token somewhere else, just that one endpoint. I have this idea maybe using a different type of Oauth 2 access token you could maybe use at different OpenID Connect providers ... if you used an [missed] RPC token you could present this at different providers that have my claims. And let's say, this RPC token was issued by a federation like InCommon, instead of like some specific university. Then I present this token for authorization to allow access to different colleges, maybe I went to undergrad at WashU and got my masters at Yale and postgrad at Harvard. By getting one token at InCommon I could provide authorization to get attributes at those three institutions, I could take that token and find out my degree, GPA, etc at all three universities. In OpenID Connect and SAML the IdP is authoritative at just one domain and there is a big gap for how we create a trusted profile of the user across many domains. ✪

Manu Sporny: There are a lot of gaps in the identity ecosystem actually. It's hard to get adoption, change user behavior, to get network economics of scale, lots of barriers to getting infrastructure to work. Do you feel that gap is aligned with the problem statement or is it misaligned? ✪

Mike Schwartz: No, I think there's room there. To give the user control to let them use that to transact business ... it's a good idea and I would also say that it should work within the existing infrastructures that are in place today. OpenID connect could give you a piece of the puzzle, other infrastructures in place. If you solve this for healthcare they'll give you a million dollars today. It's not that people aren't trying to solve it. ✪

Manu Sporny: https://herox.com/PatientIDChallenge ✪

Mike Schwartz: The problems you want to solve correspond pretty directly with what they want to do in the healthcare industry. It's a pretty hard problem. ✪

Mike Schwartz: If you have an elegant solution that you could get developers to adopt that has good usability ... the problem with most solutions is that they don't consider developer usability. The problem is definitely out there. ✪

Manu Sporny: Yeah, we are trying to get W3C behind this problem and heading in the same direction. We are having this discussion to see if you think there's a gap and if it's something that's addressable. It seems like what you're saying is that you think there are pieces out there that could be reused and there are some gaps for new tech but it's a problem worth solving and there's a path to that solution? ✪

Mike Schwartz: Yes, except I don't see a path to the solution. We're incrementally building on the solutions and tech we've had. Over the past 10 years or so ... moving from SOAP to RESTful services and from XML to JSON, the life cycle of identity standards definition has been like 5 years. So changes like that have really set back the timeframe and it's been really difficult. Getting adoption is really difficult and the community is very jaded -- why implement now there will be something better next year? Even OpenID Connect with backing of Google and MS which gave them economies of scale right off the bat -- huge head start, but OpenID Connect has take much longer than we anticipated and is still behind SAML in some ways like very few SaSS providers today. Like one or two. I see a evolution of this identity technology over time where we are adding pieces and at the same time adapting to this incredibly changing set of technologies. I'm very skeptical of any quick solution to this problem and I'd be happy to be wrong about that, it's a very challenging problem. ✪

Manu Sporny: So we're trying to figure out where this work should happen -- we've identified it's a hard problem there are gaps, etc. but we're operating out of the W3C and we have some liaisons with IETF and OASIS, etc. is there any particular standards body that is best equipped for addressing these gaps? ✪

Mike Schwartz: I'm not an expert on standards orgs -- it would be nice to maybe have a fresh look at the problem from a new space. The IETF people have been at it for a long time and there's a long history and there are certain prejudices -- and maybe we've all been wrong for the last decade and you'll come up with something. Any standards body is a workable system, I'm a big fan of OASIS. ✪

Mike Schwartz: The way IETF is run with individuals participating and you can sit in a room and write a draft and write a standard and no one contributes ... it's got pluses and minuses. I don't know. I would definitely engage with the identity experts at IETF like John Bradley, ... I'll give you a list. ✪

Manu Sporny: If you could do a quick intro with them that would be fantastic. ✪

Mike Schwartz: Yeah. Which problem space could you define well enough and address? I don't quite see where you're going with this -- the other thing you are maybe underestimating is the difficulty in identifying someone. How do you actually identify the person who is providing you the claims, is it biometric, multifactor, etc. Before you start generating claims with the service provider, you're thinking about it from a level of control, but if you think about it from the level assurance, how well was the person identified is key to integrity. You need to consider it from all three angles. How to bridge this gap between the digital world and the analog one is not as easy as you might think. Figure out where that's going to fit into your solution -- from that bridge you're sharing attributes. There's room, just bite off a small piece of it, don't let scope get too big. Lots of room to work in this area. ✪

Manu Sporny: You said a number of things in this discussion that have been really fantastic, thank you very much -- we'll take that back and share with the group. Any other concerns or big pitfalls with what we're proposing? ✪

Mike Schwartz: I don't think so. I wish you guys good luck. We talked about user centric being ambiguous -- it will bias you in the effort if you aren't really specific about what that means. One other thing I'll mention is that when people talk about level of assurance ... the usual context for that is the identity, but going beyond that is you'd like the relying party on a level of assurance on each claim. These are the sorts of hang ups you get into. Many IdPs being authorities having different levels of assurance and so on, it's a big mess and a fresh look on the problem would help in this area. ✪

Mike Schwartz: I'll send you can email with two links -- Oauth identity link and you can add that to your notes, just a new idea I had for a new identity standard. I definitely don't think we're done because we have OpenID Connect. ✪

Mike Schwartz: Other link for the reward. ✪

Manu Sporny: That would be great. We'd really appreciate that. ✪

Mike Schwartz: If you go to github/nynymike [sp?] ✪

Mike Schwartz: It's there. ✪

Manu Sporny: Thank you for your time today, Mike, it's been super helpful, we'll be in touch later on. If we put together a charter for this work we'd like to get your feedback. ✪

Mike Schwartz: If you're at RSA security -- I've got some talks there one is on authentication and the other on trust validation. This is another interesting point-- authentication isn't a one time event but as you transact you may give stronger claims/credentials. If you look at your bank, checking your statement may need X but doing a transfer might need more. ✪

Mike Schwartz: This is a partly unsolved problem how do you get interop across domains for trust elevation. ✪

Manu Sporny: https://github.com/GluuFederation/oauth-identity ✪

Mike Schwartz: To elevate trust you can't just collect different types of auth you need more claims. ✪

Mike Schwartz: Your work is cut out for you and I wish you the best of luck and let me know if there's anything I can do. ✪

Manu Sporny: Thank you, I don't think we'll be at RSA but we'll contact you within the next month or two. ✪