Manu Sporny: We have Ian Jacobs with us from W3C, Staff Contact for Web Payments work, a long time W3C veteran. We'll be talking about what the Web Payments IG is going and how our work here will impact it. We can also discuss use cases with any remaining time. ✪
Manu Sporny: As many of you know, the Web Payments IG has been looking at credentials lately, there's a topic at the NYC F2F next week where we'll be trying to extract use cases around payment credentials. ✪
Manu Sporny: I thought that it would be a good idea to get Ian on the call to introduce ourselves to him and let him hear about the work that's happening here. As a reminder, we all care about credentials very much and see it succeed. If we can do anything about credentials at W3C, we want to constructi t to be successful. We're not trying to make any decisions today, just getting background on Ian's thinking on credentials and integrating it with the Web Payments work and feedback from orgs in the education and healthcare space and what they'd like to see as far as standards are concerned over the next few years. ✪
Manu Sporny: Ian if you could give background on yourself and what you'd like to see that would be great, sorry to put you on the spot. ✪
Ian Jacobs: Manu has talked to me a bit about the work of the group and I claim only superficial knowledge of it and would like to learn more. ✪
Ian Jacobs: I'm the lead for the W3C staff for the Web Payments IG and where we are currently, having launched in Oct., is that we want to come to consensus on charters for new WGs to integrate payments further into the Web. We are meeting next week face to face where we will be discussing the work that has gone into our use cases and capabilities which are functional modules for enabling the use cases, and determining which groups, new or existing, should work on the priority capabilities we've identified for version 1. Part of the discussion is around identity requirements. ✪
Ian Jacobs: Manu has brought to the IG's attention that a lot of effort has gone into designing an approach originally rooted in payments use cases but then has migrated closer to educational and healthcare use cases. Manu and I have discussed that we an hour long conversation within the IG to solidify and get a share understanding of the financial industry's use cases. We've heard horror stories of the cost of creating accounts for high networth individiuals and creating a second account is just expensive as the first one, and credentials could lower costs. Manu has looked up the penalties involved in making sure identities are checked, and credentials can help with that. There are some prominent use cases in there already like making it easier for users to provide data to merchants like age and so forth. ✪
Ian Jacobs: Another one is for merchants/users to discuss a new payment option and there's a contractual set up beyond the technical integration and credentials could reduce costs for establishing contracts for new payment mechanisms. We want the IG to have confidence in proposing to the W3C work that would have benefit to the payments industry. That's where we are today. I know people have expressed interest in this and once, as an IG, we have a better handle on the payments use cases then we can all come together and look at opportunities to collaborate, depending on overlapping needs, and possibly move forward as a block which would be great, or as independent groups because that would be more beneficial. ✪
Ian Jacobs: I'll pause there to see if there are questions, etc. ✪
Manu Sporny: I think that's a very accurate description of where we are. If you're interested in asking questions do `q+` and you'll get on the queue. ✪
Manu Sporny: The main concern the group had voiced was in the coming together, figuring out how, if we can come up with a unified way to address all these use cases. ✪
Manu Sporny: And what the timeline would be, yet. We'd do F2F in NYC, get use cases, derive capabilities out of the use cases, then once we have that, see if there's overlap with the other credentials use cases. ✪
Ian Jacobs: You hit something on the head more clearly than we had discussed previously. Let me explain how we're using the terms. The use cases are stories, probably very similar to the work the CG has done. We want to say "so and so is paying through a website or using an NFC connection, etc." Right now it's the consumer+merchant experience. The capabilities is more about the technology needs we have for the use cases. The next level down will be requirements like "the user interface needs to be accessible, etc." ✪
Ian Jacobs: I think if we end up having the same capabilities then that suggests we have a lot of overlap and the work can go on in concern. That's less about use cases and more about capabilities. ✪
Ian Jacobs: That seems like a good thing to aim for. ✪
Manu Sporny: I don't think this group has seen the trust and capabilities document yet. ✪
Ian Jacobs: We're wrestling with the content and the display of it, and it will likely evolve again. Looking at it now is a good place to start but expect a lot of changes between now and 10 days from now. ✪
Manu Sporny: I think there's a high degree of overlap in the trust capabilities with the Web Payments and what will come out of the Credentials CG. Surely there's still work to do to establish if/where overlap is. But for the first time I think we know what we're going to use to determine if we need one or more groups on credentials. ✪
Manu Sporny: Ian, do you expect, if we're able to have a capability to capability comparison in late June/July then we could write a charter by September? ✪
Eric Korb: Manu, would that get inline for TPAC in Japan? ✪
Ian Jacobs: For me, we're trying to have a draft charter for a payments architecture, that the interest group is happy with by end of next week. At that point, in terms of process, the staff will review it, go over resource allocation, etc. There will be a membership review and a typical slowdown in August. I think having a charter that the IG is happy with in mid June would have its first F2F in Oct 2015. It takes a couple of weeks before the group launches because of the advisory committee. It's feasible to get a draft committee together in August/Sept and have work start in November. Yes, that's feasible, there's the issue of the summer slowdown (US summer slowdown). ✪
Richard Varn: This is Richard Varn with ETS. I've been working on identity security/management, for ~30 years now. I wanted to provide a perspective on that there's a real synergy between healthcare/educational credentials. I also work with [missed] retail federation to work on this. I bring a lot of different perspectives. I think to the extent possible, we would want the standards and components we use in healthcare and educationat KYC in the financial industry. We'd want it to be common, largely, and extensible where needed. ✪
Ian Jacobs: I think where we can get broad consensus on a common standard is only benefits. In our particular case, the Credentials CG, as a community, has been discussing this for quite some time and the payments industry has not. And we need to get up to speed, basically, at which point there's a lot of good will to seek a common solution without saying what it is, but seeking it is our daily bread at W3C, so I don't hear any pushback on that. ✪
Richard Varn: Here are some of the issues why we haven't moved quickly as a group, society. The people that are the custodians of records that are accepted broadly ... I would say the bear anonymous use, by and large, of credentials... the people who manage the records are document and paper based, there are few standards that they all follow, and we need to use them as a point of reference for all tehse different systems and it's difficult to get them to help. That's one problem. On the ID site. On the money side, there are a lot of financial industry conflicts, GOTR stuff. So many people have strong interest in how that works they don't want to be disadvantaged. The third issue has been the overlap with privacy, security, access, and use. That's where you end up with a discussion we've been having here, for example with short term anonymous credentials that go away quickly, etc. And you have to have discussions with privacy advocates, etc. Those are some of the backend problems we have to address, even if we have common capabilities, etc. there is a lot of drag that pulls us back. In the education/healthcare area, I'm excited that a lot of the same problems can be addressed in the same way and mroe people in those industries are aligned to help each other vs. in other industries they are adversaries. The interest in solving the problems are well aligned and what we can get done there can offer potential common solutions that people can ride on in other things. ✪
Richard Varn: To be able to go somewhere else in the same organization even helps ("we're doing this with driver's licenses, let's do it with birth records"). ✪
Richard Varn: While education/healthcare may actually help lead the way to a more common, quicker standardization method. ✪
Eric Korb: I'd like to dovetail some of the things he's talking about with regards to work in the healthcare industry and banking. We're starting to see the emergence of healthcare banking. Banks can do their healthcare and insurance payments now. As it gets broader ... ✪
Eric Korb: Credentials will get even more important. ✪
Eric Korb: We're seeing credentialing in the issuer and fulfiller of the prescription -- and that ties into payments with the person at the counter. ✪
Eric Korb: Those things could be validated at the point of sale, etc. banking and healthcare merging. ✪
Eric Korb: I think other overlaps with education are well documented. Everything starts with education. Everything else is heartbeat, so on, that we don't want to put on the internet so we need robots to handle our ID. We need to validate robots that are working on our behalf and credentials need to be validated on those claims and typically those claims are based on our education or other things about us we've achieved. ✪
Eric Korb: Also, I'd add that students pay their tution almost exclusively online. ✪
Eric Korb: Plus, gov't student loans are tramsmitted electronically. ✪
Manu Sporny: I think deployment is well care before the horse, however, Richard has been doing this for 30 years, Eric has been getting this stuff deployed and we can see what needs to be done for deployment and we know why past deployments have failed in the financial institutions. And many of that is because sharing KYC, to a certain degree, has been seen as a disadvantage. Education/healthcare has seen credentials as a big help, don't know if we can see that up to recently at least with financial industry. Richard and Eric has said you need a willing coalition/set of orgs to go and deploy this technology and get it adopted. Education primarily and the healthcare sector want to do deployments. The financial industry may jump on the bandwagon but aren't the first players. ✪
Eric Korb: Financial payments made by students, I know Xerox, a major part of their business is collecting funds/tuition. Education being a big part of state economy, would benefit from credentials in payment space. ✪
Ian Jacobs: I'm hearing a couple of different threads in the conversation. One thread seems to be that, as industries converge and the Web serves as a bridge between multiple industries, the value of a common standard goes up. We're in strong agreement on that. It's helpful to hear those use cases that cross the boundaries among the different industries. ✪
Ian Jacobs: The second thread is how to strategically address the desire of the education/healthcare community and credential CG and how to move forward and how to address the use cases and the alignment of that and how to leverage the commonality in the work. ✪
Ian Jacobs: I'm happy to engage with you in that conversation, but I don't think that's the one we need to have today. My job is to find out what the payments industry needs, it's therefore premature to think of a strategy that doesn't involve the payments folks. In my role, we need the payments people involved. ✪
Richard Varn: I hope you weren't thinking we didn't want them involved. ✪
Richard Varn: Yeah, we need them. We need payments and identity to work correctly. We've been waiting a long time. We want to see that advance. We just think they can advance better together. ✪
Ian Jacobs: I apologize for the blinders I have on... my limited perspective is having a valuable and informed discussion on identity and credential needs. I need to hear more from you in historic pitfalls in what has been tried and how this work takes those into account and is different. For example, Richard/Eric said that the banks may resist change, is that something that is going to doom in the IG to failure or there's simply lessons learned so we can be sure to take the economics into account in our discussions so even with competing interests we can be explicit about them or even better find corresponding benefits for interested parties. Also, who is stepping up from the Web community for the particular approach being taken by the CG? It's possible even to have... to split the conversation to have the functionality we need and we're all in agreement in that, but it may be harder to get agreement on a particular solution because we have different communities within W3C like SemWeb who may want JSON-LD but that may be in conflict with the broader community. ✪
Ian Jacobs: Those are all things I want to hear and get us on the same page. ✪
Ian Jacobs: [Ian understands that mosaic of credentials will paint a picture of identity] ✪
Richard Varn: I was going to add that the one part of this about this that overlaps in the Identity space is the collection of credentials. In the way a wallet provides a set of evidence about who someone is, credentials does that, there's going to be a diversity of opinion on ways people will do that, we'd have one very hard to crack token and maybe people want that but that's unlikely and other people want to do more diverse things. We want to have credentials that are difficult to fake because they are based on a whole portfolio of things that are based on industries that issued them etc. (missed some) ✪
Manu Sporny: So why have these other credentialing mechanisms failed? There are a lot of broad ID mechanisms like OpenID/Connect, and those have failed to address these use cases because they don't carry high-stakes credentials; they can establish you have an account with facebook but they are incapable of expressing information like citizenship, proof of age, etc. We have technologies that are fairly naive about the information they carry. They have attributes that are self-asserted, not countersigned by trusted authorities/issuers. We've seen this happen in healthcare and education: the solutions only take one industry into account, gov't have adopted piv tokens for federal security/buildings/etc. There's an entire ecosystem around credentials but that's never taken into account in these smaller solutions. Banking has focused on credentials only for banking, and then adopted proprietary and patent-encumbered tech, to get "latest greated" so that was really expensive. Then the orgs that actually exchanged the credentials were operating on a non-public network, so under 10K orgs worldwide able to use them. They were never deemed to be more broadly applicable. So different problems with previous solutions. The industries tend to try and address them in a fairly insular fashion and we just want to try and fix them in our industry and we're sure it will propagate out to others. And using proprietary and patent-encumbered tech has been a problem sometimes turning out to be snake oil. I think that's over simplifying it, if you look at any identity/credentialing systems before now. Problems: 1. No high-stakes creds in scope when building the tech out (OpenId/Connect), 2. Industry only took their market vertical into account., 3. Belief that proprietary tech was best, but patent-encumbered ruined scalability with cost, etc. ✪
Manu Sporny: I think those are the primary reasons ✪
Richard Varn: There came as an insistence that a privacy (missed) be agreed and enforced through the identity security mechanisms. I've had all kinds of discussions in different industries -- and trying to force identity/security/privacy all through the same mechanism it doesn't have to be the same. ✪
Ian Jacobs: Can you say more about the particular community/communities that have been involved in the development of this. It is often the case that without browser awareness, it becomes harder to get browser deployment. It may be that support in browsers is not a key piece in the deployment of this, in which case understanding that would be helpful. I don't know if in the Payments case browser support is a key piece of it, etc. I'd like to hear your views on the role of the browser and the ... support of this. ✪
Manu Sporny is scribing.
Dave Longley: We've been having discussions with the WebAppSec group at W3C regarding a credential management API that they've been working on. ✪
Dave Longley: They primarily started that spec to make it easier for browsers to manage passwords for people. People use a lot of tools to autofill passwords. They're taking baby steps to get direct access to password manager for websites. ✪
Dave Longley: They're also trying to make the system extensible and work with federated credentials - we saw the work happening, gave feedback. They had been creating something called a 'credential management API' - we saw lots of overlap. ✪
Dave Longley: We had built out something similar - we thought that if we could build a credential agent in the browser, and we could hook that up to people's identity providers and we could hook that back to websites. We'd like to see an API in the browser to request credentials that the website needs. ✪
Dave Longley: We wanted the browser to go fetch the credentials when asked - given permission by recipient - etc. ✪
Dave Longley: Ultimately, that's the role we'd like the browser to play - to protect privacy of person using credentials. ✪
Dave Longley: No, we want to prevent it from tracking you. ✪
Dave Longley: We want there to be a system that holds on to your credentials, but they don't know who you're giving those credentials to. ✪
Dave Longley: The other piece in the browser is providing a mechanism for issuing websites to use to issue credentials via the browsers. ✪
Dave Longley: To tie it back into credential management API - API that they designed allowed websites to ask for previously stored passwords or credential tokens... they had the same sort of idea of how the API would work, but their current spec is very narrowly focused on just the login case - primarily the password case. ✪
Dave Longley: We'd like the scope to be broader - we see the future of the Web to be a bit less about login and more about having credential to get access to a particular portion of a website. ✪
Dave Longley: Certainly, usernames and passwords will continue to be used - but you can get more granular with community groups. ✪
Ian Jacobs: I know there have been questions about identity management around domains - what in the conversations w/ WebAppSec and w/ browser vendors specifically - was there any feedback on lack of interest on this general approach? ✪
Ian Jacobs: Were there other questions around support or reluctance around this idea. ✪
Dave Longley: There has been pushback - first was that the WebAppSec was not chartered to deal w/ our use cases in any way. We came up w/ a proposal to support generalized credential use case. ✪
Dave Longley: The Chair of WebAppSec pushed back and questioned that the API was a good for both cross-origin and same-origin credentials. ✪
Dave Longley: Mostly people want to stay w/ same origin policy - we don't want to touch that too much ✪
Dave Longley: This is something that needs to happen on the Web, just because there is a secure way to secure certain types of data. We shouldn't say we're not going to look at it. ✪
Ian Jacobs: So, I think that's a big hurdle. I've been hearing that tracking is important in some ways, and in other cases we care about privacy. ✪
Ian Jacobs: The default expectation on the Web - the things that we enable that allow tracking is problematic. ✪
Ian Jacobs: So, I'm hearing two things - we want to support certain use cases that require tracking, but others we want to default to privacy. ✪
Ian Jacobs: We may need to do something about same origin vs. cross origin policy. ✪
Manu Sporny: I think there's one point I want to make before we hang up and that's the thing that we've found with the WebAppSec group is that the charter was very narrow on the type of credential they were looking at. That meant whenever we get close to talking about the meat of the discussion, the charter got in the way. In my personal opinion, we know that what they are trying to do is not the best thing for the Web. There are password managers out there, building that into the browser may cause lock in problems, then Chrome shares all passwords within Chrome and it's difficult to export to Firefox, etc. and that's being swept under the rug. And just because we understand the same origin policy very well, that doesn't mean there aren't very good use cases for cross-origin credentials and there are ways to secure some of that information. The problem is whenever we try to have a discussion about it it gets shut down. So charters or security people get nervous and it gets shutdown. So "this makes me nervous, stop talking." ✪
Ian Jacobs: Have you scheduled a chat with the security IG or TAG, etc.? ✪
Manu Sporny: Talking with the security group has resulted in people feeling nervous and not wanting to discuss and TAG would take a lot of time but it's something we have to do. ✪
Ian Jacobs: Raising awareness of the TAG needs to be considered because some of what you have heard may be "This is how the Web works for security" (I'm imagining that as something people might say). And we need to check in and see if the TAG really thinks that's true and we may need to push boundaries. Just like the Web has moved into a place where JS has a more prominent role vs. angled brackets. I think it's worth having the TAG there as an architectural grounding influence. Post IG meeting, that may be something to look into. With Wendy (Seltzer) she's our security lead and we can discuss with her. We didn't get to the economics of credentials and I imagine they are different for each industry or if not what's similar? I'd like to see who would want a vibrant open market for credential providers. What's the expectation for gov't agencies to step up, what about people who don't want to use these IDs, maybe there are countries that have done IDs successfully, how will the economics work and I'm particularly interested in the payments landscape. ✪
Manu Sporny: I know Richard has a tremendous amount of experience in that space and hopefully we can use his time in NYC to dig in deeper with that. Thank you, Ian for joining. ✪
Manu Sporny: We won't have a call next week because the Web Payments F2F will be going on and a number of us will be there. Thanks all! ✪