Verifiable Claims Telecon Minutes for 2016-01-29

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-29/

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-29

Agenda:
  https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Jan/0068.html
Topics:
  1. Introduction
  2. Problem Statement
  3. Level of assurance, Level of protection, and Level of 
    control
  4. The Problem with User-Centric
  5. Important Trust Models
  6. OpenID, SAML, and Privacy
  7. Potential Standardization Opportunities
  8. Best Place for Standardization Work
Organizer:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, Mike Schwartz
Audio:
  http://w3c.github.io/vctf/meetings/2016-01-29/audio.ogg

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

Topic: Introduction

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.

Topic: Problem Statement

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.

Topic: Level of assurance, Level of protection, and Level of control

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.

Topic: The Problem with User-Centric

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.

Topic: Important Trust Models

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?

Topic: OpenID, SAML, and Privacy

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.

Topic: Potential Standardization Opportunities

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.

Topic: Best Place for Standardization Work

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.

Received on Friday, 29 January 2016 21:45:44 UTC