Verifiable Claims Telecon Minutes for 2016-01-08

Thanks to Dave Longley for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:

http://w3c.github.io/vctf/meetings/2016-01-08/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
Verifiable Claims Telecon Minutes for 2016-01-08

Agenda:
  https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Jan/0016.html
Topics:
  1. Verifiable Claims Problem Statement
  2. Anti-Fraud / Anti-Abuse
  3. Revocation / Status Checking
  4. Slow Evolution of Agent-Centric Protocols
  5. Trust and Semantics
Organizer:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, Brad Hill, Brian Sletten, David Ezell, 
  Eric Korb, Matt Collier, David I. Lehn
Audio:
  http://w3c.github.io/vctf/meetings/2016-01-08/audio.ogg

Dave Longley is scribing.
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.

Topic: Verifiable Claims 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.

Topic: Anti-Fraud / Anti-Abuse

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.

Topic: Revocation / Status Checking

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.

Topic: Slow Evolution of Agent-Centric Protocols

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.

Topic: Trust and Semantics

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.

Received on Friday, 8 January 2016 18:31:12 UTC