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

Regrets for tomorrow's VCTF meeting. I may be able to pop in partway through.

Gregg Kellogg
Sent from my iPhone

> On Jan 8, 2016, at 10:30 AM, msporny@digitalbazaar.com wrote:
> 
> 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.
> 
> 
> 
>