Manu Sporny: Brad Hill has been a Security Engineer at PayPal, the FIDO Alliance, and is now at Facebook. He is also the co-Chair of the Web Application Security Working Group at W3C. He is here as an individual and is NOT representing WebApp Sec or his company in any capacity. ✪

Manu Sporny: We'd like to talk with you today about the Verifiable Claims Task Force proposal and your thoughts, the conversation will be driven by you, whatever you want to talk about, we'd like to hear about. If there are any key questions we think were missed we can go over at the end. ✪

Brad Hill: I've put down a lot of my thoughts here: https://docs.google.com/document/d/1aFAPObWUKEiSvPVqh9w1e6_L3iH4T08FQbJIOOlCvzU/edit# [scribe assist by Manu Sporny] ✪

Brad Hill: Sounds good. I've put down some of my thoughts in a Google doc, I've seen it's gotten a lot of readers and comments, it's as good of a way to start as any. ✪

Manu Sporny: Ok, let's go through the doc first then. ✪

Manu Sporny: Let's start with the problem statement. ✪

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

Brad Hill: I think it's fine. The thing that stood out to me was the part about not changing service provider without losing digital identity. A lot of the claims that are interesting have canonical issuers and I can't port them anyway. ✪

Brad Hill: I'm not sure what's imagined by identity portability. ✪

Brad Hill: Which of the three parties that you're porting claims between is unclear. ✪

Manu Sporny: That hasn't been proposed as a work item (porting between issuers). The idea here is that there may be multiple issuers that say, for example, you've passed the SAT, GRE, or issuers for driver's license, passports, etc. There would only be one issuer for many of those like the US government. But for other things like learning credentials that say you've passed a particular credential there would be lots of issuers. When we're talking about portability, we're saying that once a credential has been issued to an individual or organization, they can choose where to store that credential. It's the user's choice ... a digital wallet, a online service, etc. And they can change it. ✪

Manu Sporny: Does that clear that up? ✪

Brad Hill: Yes. ✪

Manu Sporny: Now that that's clear are there any concerns? ✪

Brad Hill: There are some questions about trust like is the trust proprietary or are the technologies, etc? But we can talk about that later. ✪

Brad Hill: Otherwise no. ✪

Brad Hill: I think the statement that "there is no standard that makes it easy for users to assert qualifications to a service provider" isn't entirely accurate. If you look at SAML for instance, tech that has been used to transfer claims for rights and entitlements, used in the education sector, etc. I think it's been used in a number of places and it would be worth doing some more tech history around SAML and what that ecosystem looks like and looked like and if it didn't catch on where it's worth mentioning as a viable competitor today, the reasons why/why not would be good. Finding out about systems in Europe and educational systems would be good. Maybe there isn't a user centric version of that, but there are service centric ones that meet that claim. ✪

Manu Sporny: Certainly SAML is one of the techs we will do a deep dive on in the task force. ✪

Manu Sporny: There are places where SAML is widely deployed like you said, they have said that it's not ideally suited for some of the types of use case they have. So we have talked with very large orgs in the education sector that have SAML deployed who have said it's not viable. ✪

Manu Sporny: But you're saying do a very deep dive with SAML and talk about what's not working and the pitfalls, etc. ✪

Brad Hill: Yeah. ✪

Manu Sporny: Can you think of any other systems that are similar to SAML in this respect? Cross-industry standard that can express and exchange claims? ✪

Brad Hill: OAuth is similar but if you want to look at the history of large scale efforts for exchanging this type of info SAML is the best case to look at. ✪

Manu Sporny: So we should rework the problem statement to talk about SAML. ✪

Brad Hill: If I'm a CTO somewhere and I've been around for a while and I've spent 10s of millions of dollars and I've seen SAML then I want to see in the problem statement what would make this new tech more successful than SAML. ✪

Manu Sporny: Ok, any other concerns with the problem statement? ✪

Brad Hill: No, makes sense. ✪

Manu Sporny: Makes sense that it's something we should look into or do you feel that something positive won't come out of it? ✪

Brad Hill: I think that this is something people have wanted for a long time. It's an obvious way we interact in the real world and we want to bring it to the digital world and there are challenges and difficulties in doing that so I've tried to highlight some of those in the google doc. I'd like to help make this attempt more successful. It's something to attempt or at least desire. ✪

Manu Sporny: We're very thankful for that document and we're going to be taking what you wrote and what others wrote in an output from the task force on things to look out for. ✪

Manu Sporny: Ok, let's go with general concerns about user-centric architectures next. ✪

Manu Sporny: Have you had a chance to read some of the feedback/comments in the google doc you wrote yet? ✪

Manu Sporny: If not, we can talk about fraud and abuse section. ✪

Brad Hill: Hopefully I've said it fairly well, there are other types of architectures and systems... there are some things where user agents take some responsibility in this regard, there are things like smart screen from MS, so on... if a credential gets stolen out of your device by malware, then your agent is no longer in the loop to provide that bubble of protection and then who has visibility into how you deal with that. ✪

Brad Hill: In service-centric systems the service always knows where the credential is being used. ✪

Brad Hill: If someone clones my credit card then no one knows it's being used and that's difficult. ✪

Brad Hill: In large companies and at large scale, having a clearing house that can do analytics, etc. helps with fraud. ✪

Manu Sporny: Do you think that a user-centric approach fundamentally cannot provide the same types of protection? Or can it be modified, such as a digital signature must be put on a credential when it's exchanged to lock it down, etc. ✪

Manu Sporny: Is it possible to make a user-centric system as powerful as a service-centric one w/respect to fraud/abuse or can you do things in a user-centric system to get the same level of protection? ✪

Brad Hill: I think there are ways you can do better than nothing. You can have a token binding to a key like you mentioned. I don't know if that impedes on your goals w/portability. I think there are fundamentally ways that service-centric archs can provide protection over user-centric. Large orgs can do that, whereas users may choose to interact with entities anyway because they don't know better or don't care. ✪

Brad Hill: Where are how and what users are allowed to send credentials to is hard to control. ✪

Manu Sporny: Do you think if there was such a user-centric system and it was successful, would it be a bad thing? Would the fraud/abuse problem be something that can't be addressed by a user-centric system? Are you saying even if we put as many protections as we could, the ecosystem would make us worse off than we are today because of this architecture? Because there aren't orgs that are being paternalistic about what you can/can't do... would it be worse fundamentally? ✪

Brad Hill: I think it's not a question of fundamentally worse, it's just a set of techs that will compete with service-centric arch, and if you don't do as much of a good job making people be able to use it with reasonable degrees of trust and assurance then people won't use it. It will be a competition in the marketplace. ✪

Brad Hill: You should think of the best possible way to do it. ✪

Brad Hill: To be successful. ✪

Manu Sporny: So the issues are addressable but we have to keep eyes open and do good analysis. ✪

Brad Hill: I can't say, there are a lot of moving parts in the system regarding complexity of the tech and adoption and what scenarios you want to support. ✪

Brad Hill: I can just say it's something to think about carefully and trade off against a lot of other concerns. ✪

Manu Sporny: Any other thoughts/concerns on fraud/abuse before moving on? ✪

Brad Hill: Nope, I've got things in the doc, but not comprehensive, only an hour and half to work on, etc. ✪

Manu Sporny: Ok. It seems there's an assumption that long-lived credentials are hard to check status on. ✪

Brad Hill: No, it's just a design decision to think about. You look at systems where you need to ping back to assurers to ensure things are still valid, but a loss of privacy. But there are ways for the user agent to get up to date status information and sending it along when exchanging, that was mentioned in the comments as an alternative. You just have to think about these things and they impact the complexity of the protocol. ✪

Manu Sporny: There are four combinations the group has been looking at. 1. A long-lived identifier as a person w/a long lived-credential assigned to one of those IDs you own, and you can crypto-prove you own it. It's like a driver's license that you can have for multiple years at a time and there's some revocation list associated with it. ✪

Manu Sporny: 2. When you get that long-lived credential there's a way to convert it to a short-lived credential and you can unbind your long-lived ID from it and you can do this conversion and hand over a short-lived version of it to give pseudo-anonymity. ✪

Manu Sporny: 3. A short-lived identifier with no revocation list. ✪

Manu Sporny: 4. Short-lived credential requested on demand, bound to a channel ID. ✪

Manu Sporny: Those are the four mechanisms we are looking at for how these credentials are used, etc. ✪

Manu Sporny: Do you feel that that handles all the cases, with long-lived credential tied to a long-lived ID, to short-lived, etc. Do those cover the types the ecosystem might need? ✪

Brad Hill: I'm not sure, it's the first time I've heard those four things ... but can't say if comprehensive at this point. ✪

Manu Sporny: Any of those seem crazy? ✪

Brad Hill: It makes reasonable sense, I don't know if revocation list is the right term, it sounds like it applies to more than one credential. I don't know how to square that with privacy concerns. ✪

Manu Sporny: Yeah, wrong term, there's some revocation information for your credential and your agent can refresh that for you. ✪

Brad Hill: Stapled-revocation information. ✪

Manu Sporny: Ok, we'll use that terminology. ✪

Manu Sporny: Anything else on revocation or status checking you'd want to discuss? ✪

Brad Hill: No, mostly ... hmm, mostly I feel like you're asking for my endorsement. I'm not hear to do that, I've raised some concerns. I can't endorse that the concerns will all be addressed because you can't say this will be a 3 or a 4 ... it's big and complex. ✪

Manu Sporny: Yeah, to be clear, we're not looking for endorsement, we want as much raw input that we can have. ✪

Manu Sporny: We want to see if there is anything unreasonable that you can point to and say "that looks really wrong." ✪

Manu Sporny: If we said "we're only doing long-lived IDs and no revocation" you'd probably say that that sounds bad for a broad ecosystem. ✪

Manu Sporny: That's the kind of feedback we're looking for. ✪

Brad Hill: Ok, but I've only looked at the problem statement so I can't speak, on the fly, to any particular proposals and if they'll work with large ecosystem concerns, it's more about balancing all of these things to create a successful ecosystem. ✪

Brad Hill: So, we have the example right now with trying to transition away from SHA-1 in TLS. And it's a protocol in the hands of consumers out there on the Web. It's a hard transition to make. Lots of lots of people still have browsers that use SSL 3.0 only that was obsoleted 12 years ago. Lots of people have devices that have to be entirely replaced to upgrade. There are elderly people who have the same computer they've used for years, still Windows 95 out there. Google is saying "we're using OpenID Connect and turning the rest off" and Google can do that and a billion users can get those newer, better features. That's different from needing to upgrade all the user agents in the field. ✪

Brad Hill: And you have vulnerabilities that last a long time. ✪

Manu Sporny: Ok, certainly distributed systems have those downsides... ✪

Manu Sporny: http://w3c.github.io/vctf/#design-approaches ✪

Manu Sporny: So we've got this list of service-centric qualities down at the bottom. ✪

Manu Sporny: [Lists some qualities] ✪

Manu Sporny: Do you: 1. agree that those are downsides to the service-centric approach? There are downsides, do you think there are more, do you disagree with what we have? ✪

Manu Sporny: What are your thoughts? ✪

Brad Hill: I don't know if those qualities are all downsides. I don't know if silos is correct. I can use any user agent to get info from facebook, etc. ✪

Manu Sporny: That means you can't get a digital driver's license and put it in facebook and then use it on another driver's license. ✪

Manu Sporny: Does that make sense? ✪

Brad Hill: I guess, but you can get your own PGP key and publish it on facebook or in another place. ✪

Brad Hill: Using "agent" here is confusing because it is a browser or a digital wallet or what? ✪

Manu Sporny: Does it make more sense if you take agent out and make it a service silo? ✪

Dave Longley: I was going to ask - are there pieces of information specific to users, not specific to a particular service - social relationships, associate them with themselves, move them to different social networks. [scribe assist by Manu Sporny] ✪

Dave Longley: So, they don't have to define all of those in a particular service. We're trying to figure out how you can capture information like that in this problem statement. [scribe assist by Manu Sporny] ✪

Brad Hill: The most common claim is email address - you control that - Google asserts my work email address to other people - OpenID Connect sign in. I control that address. Far and away, most common claim type, canonical issuer of email - email provider have address with me - lots of issuers are trusted to make that claim. [scribe assist by Manu Sporny] ✪

Dave Longley: That kind of thing we'd like to see more of - so it's not just email addresses - before you could do something like that, you have to do that over and over at different services. [scribe assist by Manu Sporny] ✪

Dave Longley: In this case, the issuer shouldn't have to change - you only need one issuer for that email address - help reduce fraud, carry those claims with you, use them at other services. You should be able to do this sort of thing w/ other claims. [scribe assist by Manu Sporny] ✪

Dave Longley: If you have to go back to each issuer, and that's the only issuer that can supply the claims. You want to collect those claims - you on a particular issuer - that's the user centric model. I am someone and I want to collect these claims from a variety of different issuers. As long as consumers trust the issuers, the system works nicely. [scribe assist by Manu Sporny] ✪

Brad Hill: I understand that's what you're trying to build - that doesn't mean service-centric claims are locked into service providers. I think the hardest/most interesting part is who is trusted to assert which claims and why. [scribe assist by Manu Sporny] ✪

Brad Hill: That's a problem in service-centric/user-centric world. [scribe assist by Manu Sporny] ✪

Dave Longley: Identity providers (curators) hold on to your credentials, the way the model works with SAML, the issuer is the provider, you have to go off to individual services and identify yourself. Your identity is bound up with each one of these issuers. Where that identity is either long-lived and cross-domain or it is specific to a particular site - you can get credentials issued for that particular site. That's pushing the user to the center rather than having [scribe assist by Manu Sporny] ✪

Manu Sporny: All these different services having these views of people. ✪

Brad Hill: I get it - the problem statement there, and the properties should be qualified how service-centric systems work. Not a question of how user-centric system is supposed to work. [scribe assist by Manu Sporny] ✪

Manu Sporny: Do you want to talk about costs and trust/semantics? ✪

Brad Hill: Trust and Semantics is the most interesting one. ✪

Brad Hill: There is no simple answer and how you build a successful ecosystem is hard to do. Given a case study with SAML, Susan Landow has a good paper on this. ✪

Brad Hill: It's a good talk about competing economic issues of the competing parties and why those other systems haven't taken off and how we bootstrap that kind of trust and the meaning and semantics of claims in an arbitrarily extensible system ... ✪

Brad Hill: Susan Landau (economic coupled with single sign on) - on SAML and Federation and economic incentives and why those systems haven't taken off. [scribe assist by Manu Sporny] ✪

Brian Sletten: http://weis2011.econinfosec.org/papers/Economic%20Tussles%20in%20Federated%20Identity%20Management.pdf ✪

Brad Hill: [Missed] it was too complicated for people to figure out the business problems. ✪

Manu Sporny: So your statement is more of a "what are the business models that will make this work?" ✪

Manu Sporny: The assertion is "This ecosystem is very costly to set up, so you need to make sure there is a business model that supports that cost." ✪

Manu Sporny: Is that the gist? ✪

Brad Hill: Yeah. If you want it to scale better or be competitive with service-centric stuff... people use super providers now. If I want to get people to sign up I can just put Google, Facebook, etc. on there and I'll get users. "Nobody ever got fired for going with IBM" idea. If there are a bunch of providers is that viable, etc? Presumably some of my employers do... but checking university credentials is a big deal, people getting fired for falsifying that stuff. ✪

Manu Sporny: We're seeing a lot of movement in the education space and a lot of participants in the work are from that sector. When people have a degree, did courses, etc. how do we make that stuff easier to check? We are engaging with that community and there are business models they are very interested in pursuing ... and one of the problems we're having is connecting folks like you that are raising these questions and the orgs that want to use it. I don't know if it would be helpful for you to talk to those orgs to see that there are business models there or poke at them. Figure out if you've done a cost analysis on X or Y. ✪

Manu Sporny: Would you be interested in discussing this with the education industry? ✪

Brad Hill: If you guys are doing that, that's great. This is not my project, I won't engage with other industry partners, they shouldn't care if my concerns are addressed, you should care. ✪

Brad Hill: If you think these are valid concerns you should think about addressing them. I don't think my endorsement turns on this one or another. ✪

Manu Sporny: Yeah, it helps for us to get this kind of feedback from you because we can take it to the education industry and they need to lay out their needs clearly because if you are a security researcher and not over there you don't see that. ✪

Manu Sporny: We want to ask what kind of work product. ... let's say we go down this user-centric route and there's something to work on, what do you think that should be. For example if the group decides this is something we should be doing... do you think a baby step for coming up with a standard format for expressing verifiable claims is valuable? Do you think the first step would be coming up with a data format for that stuff? Don't talk about protocols, etc.? That's an example of a baby step, or do you think that coming up with that is somewhat in a vacuum, without thinking about the protocol would be a mistake? Can you point to a phase 1 of a WG? ✪

Brad Hill: What are the parts that need to be standardized? ... You want to have portability between agents then that needs to be standardized. How does the agent work and how does it communicate? What are the interfaces between the agent and the issuers and the agent and the consumers for this basic architecture to succeed. ✪

Brad Hill: That's the part that needs to be standardized. ✪

Manu Sporny: The pushback we have on that is that it's too bold and we could start with the format of the claim first and phase 2 we talk about the agent and how it interfaces with the other parties. ✪

Manu Sporny: Should we do that or just go ahead with doing both? ✪

Brad Hill: You can approach it either way. ✪

Brad Hill: Maybe defining the claims format first, if and what, the business cases are and what the interest is to drive it going forward. ✪

Manu Sporny: So failing at a basic format means agent protocol is unlikely. ✪

Brad Hill: Well, not that you'd fail but if we can do this is it interesting enough to get people to use these types of claim, and would it build support for going further to talk about delivering them to people, etc. ✪

Manu Sporny: We are asking everyone we're interviewing the same question... if there's something to work on, what is the smartest thing to work on first? ✪

Manu Sporny: If we circulated a charter to do a basic credential/claim format understanding it will fit in a larger ecosystem ... do you think W3C membership would respond favorably or not? ✪

Brad Hill: I don't know. ✪

Manu Sporny: Ok, that's a helpful answer. ✪

Manu Sporny: We don't know how they'd respond either. ✪

Manu Sporny: Do you think another standards membership body would be better qualified to work on this or might as well do it at W3C? ✪

Brad Hill: Certainly, a lot of the community experience with the service-centric protocol is not in the W3C. OAuth, OpenID, OpenID Connect, SAML, those have come out of IETF, OASIS Foundation, etc. To the extent you want to expertise of people in the general problem space with a different architecture they aren't by and large super active at W3C. There are people at W3C like Jeff Hodges. But the W3C might be the most interesting place to do this in terms of the user agent. ✪

Brad Hill: It's probably something that looks a lot like a web browser, this "wallet" thing -- or an extension or part of it. ✪

Brad Hill: I would reach out and establish a liaison with other groups. ✪

Manu Sporny: Yeah, we plan to do that. Part of this is getting those folks involved, for example Drummond Reed, OpenID, XDI, OASIS, ... Christopher Allen who co-authored SSL/TLS. We plan to engage with SAML, LDAP folks as well, etc. ✪

Manu Sporny: Is there anything else you wanted to mention or talk about today, Brad? ✪

Brad Hill: I think that's it. ✪

Manu Sporny: Thank you so much, I really do appreciate you taking the time you took, you're really busy. ✪

Manu Sporny: I hope we can reach out again if we have more concerns. ✪

Brad Hill: Sure. ✪