Web Payments Community Group Telecon

Minutes for 2014-03-05

Agenda
http://lists.w3.org/Archives/Public/public-webpayments/2014Mar/0024.html
Topics
  1. Web Payments Mobile Use Cases
  2. Persona and Web Identity Spec
  3. Decentralized Credentials-based Login
  4. HTTP Signatures
Chair
Manu Sporny
Scribe
Dave Longley
Present
Dave Longley, Natasha Rooney, Manu Sporny, Erik Anderson, David I. Lehn, Brent Shambaugh
Audio Log
Dave Longley is scribing.

Topic: Web Payments Mobile Use Cases

Natasha Rooney: Hi Natasha from GSM Association, big mobile standardization organization, Brent has offered to help out on mobile payments use cases, what we're doing is taking use cases for how payments exist on native platforms, possibly in proprietary solutions on the web, and documenting how they work on mobile
Natasha Rooney: Thx for putting up link to github page, there's also a wiki, the work is in two places, i'd like to move both into github, my preference
Natasha Rooney: Or continue to work on the wiki, the issue there is that the mobile access group doesn't have access to the wiki
Manu Sporny: The wiki was meant to be temporary, we didn't want 20-30 PRs out there conflicting, we wanted a rapid way to dump information in there, and then organize and move back to github
Manu Sporny: If you feel there's enough information there please pull it back into github
Manu Sporny: There are some outstanding questinos there we'll get to later
Manu Sporny: We wanted to be able to iterate on it quickly and github PR was maybe going to slow it down
Natasha Rooney: Makes perfect sense, i'll pull things into github repo
Natasha Rooney: I went through the wiki style use cases, got criticized by co-chair saying we really should document solutions that exist across native platforms, and that experience on mobile, if you scroll down to the paypal section on github, there's an example of what i'd like to produce for all of the other native applications/plugins/proprietary apps
Natasha Rooney: I've put in regions where it operates, capabilities, APIs to develop
Natasha Rooney: I consider API very interesting as something we could use as a standardization body to create an API later on, not wanting to get into a legal discussion now there are legal issues, just a good guideline
Natasha Rooney: We'd like help from both this group and the rest of the mobile interest group as well, we want a robust set of use cases for payments for mobile
Natasha Rooney: Manu you mentioned questions?
Manu Sporny: I think you answered a good chunk of them, the main thing we were concerned about -- some of the use cases weren't use cases but feature sets, some people disagree on what "use case" means.. don't want to get bogged down there... so we've been taking any use cases we can see from websites for payment providers and also pulling any features that seem important but can't be categorized as use cases and documenting those too. Your developer API sections make more sense to me now, might be difficult to get all that information together before W3C Web Payments Workshop.
Manu Sporny: The high-level question is .... it's confusing how we should categorize mobile payments use cases vs. just web payments use cases, because as you said there's a lot of overlap, so in general we've been trying to capture everything and then we can pull the mobile bits out of everything, the reason for capturing everything is that we dont' have a document outlining all the payment systems out on the web today so this would be a good opportunity to do that, and at the same time we'd get the mobile use cases
Manu Sporny: In particular did you have a way that you wanted to classify the mobile payments stuff? What qualifies a mobile payments system
Natasha Rooney: I was taking the approach of everything as well, focusing on everything means there's a lot of work to do, but not focusing on it and thinking just focusing on the desktop issue may cause issues later on, think of this instead as a data-gathering exercise and then from that data identify the use cases, so when i looked at google wallet and paypal there was a common set of use cases
Natasha Rooney: So i think one doc for data and then have another doc that identifies use cases and put data underneath it would work
Manu Sporny: Yeah, my concern is getting something to the web payments workshop that's useful, i feel we have a decent chunk of work in front of us that could be reduced by just doing a fairly high-level pass of these systems
Manu Sporny: We still capture a good chunk of common use cases
Manu Sporny: For example, being able to pay with a digital wallet that supports credit card and bank account
Manu Sporny: We have a lot of these payment mechanisms out there on this web payments mobile use cases page, but if we do just a really quick scan across the site, 10-15 minutes per platform we can get a good high-level summary of the types of features that there are, we won't be able to get deep into development API, but we can get what each site thinks are the most important features that they provide, that way we can get this done in the next week hopefully and then there's a week left to get things down to something the workshop can use
Natasha Rooney: Makes sense i can find key cases that exist between them
Natasha Rooney: I forget how close it is to the workshop
Natasha Rooney: After this call, i'll do that email to both groups about what we're going to do now and hopefully we'll get some people to help brent and me out here
Natasha Rooney: Feel free to raise an issue on the github repo, if you have a particular thought, don't feel you'll have to deal with it, if you're silent we won't know about it, please be vocal
Manu Sporny: Let's say the deliverable to the workshop is the first iteration of the use cases, after that the CG will want to go back in an expand out each of the high level things, we'll want to do a deep dive into dev APIs for types of calls they provide, things like that, do you want to coordinate through the payment use cases thing throuhg the web and mobile group or do this somewhere else? seems this will turn into a living doc on all the payment systems out there, i'm happy to put it in the payments use cases repo, if you think that's something the web and mobile group would be interested in to collaborate on.
Natasha Rooney: Yeah, i think you guys should eventually pull it in, it can stay where it is now, but you guys can pull it over later it would be best
Natasha Rooney: We can still work on this with you guys of course, you can always get me to join a call, we can have that discussion about what other work needs to be done
Manu Sporny: The rough plan then is to get as many people as we can get to keep fill out the use cases wiki, preferably following the format of the paypal example in the github repo (payments use cases repo) and once we're done filling that out, you (Natasha) will pull the pieces you think are applicable to mobile payments into the github repo and do some editing there, and whatever that doc ends up becoming it's one we will provide to the web payments workshop
Manu Sporny: After the workshop, we'll figure out a way of more properly getting all the information together and maybe we'll put it into a respec format or github repo or something and continue to add deeper info about dev APIs and other things that aren't quite apparent at first glance from lookign at this websites, that sound good?
Natasha Rooney: Absolutely perfect, you've got it all
Erik Anderson: No input from me, all good discussion
Natasha Rooney: I have to run, but it sounds good

Topic: Persona and Web Identity Spec

Manu Sporny: The spec's been worked on for a while now, the spec covers ways to identify people, home address, KYC, email, payment systems and banks need this info, the web identity spec defines a mechanism for storing that info and retrieving it in a decentralized way
Manu Sporny: When you log into a website you can provide your home address, credit score, govt ID, etc. in a way that's digitally signed, your govt ID for example could be signed by your national govt and your bank could depend on it
Erik Anderson: I have a call with the Department of State later on this week concerning this subject
Manu Sporny: We're also working with an entity in the education arena and they have millions of identities that they have to identify on a yearly basis... they have to ensure people have university degrees, make sure people have credentials to do surgery on people, practice medicine as a nurse, things of that nature.
Manu Sporny: This is cryptographically verifiable identity stuff, where it really matters if that doctor that is going to operate on you is qualified, or that multi-thousand dollar transaction you're going to do is actually approved by you, etc.
Manu Sporny: We've been operating with this name "Web Identity" for a while now which is confusing because there are other identity specs out there, this spec is more about verifiable credentials
Manu Sporny: The idea to rename the spec to "identity credentials" or "web credentials" or "entity credentials" has been floated
Manu Sporny: The idea here is to help people understand that while identity is an aspect of this it has more to do with verifiable credentials than not
Manu Sporny: I think the current proposal is "web credentials" or "identity credentials"
Erik Anderson: "Digital credentials" works too
Manu Sporny: Stephen rowat pointed out that "web" isn't that useful in the name
Manu Sporny: "Digital" is sort of like "web" here, doesn't add all that much
Dave Longley: I agree that "identity credentials" is better. [scribe assist by Manu Sporny]
Erik Anderson: "Identity credentials" ... people want to be anonymous on the web, could bring library of congress in - lots of people do identity, you want to show up well on searches.
Erik Anderson: Might be hard to find (too generic)
Manu Sporny: We do want the name of the spec to be fairly unique
Manu Sporny: "Digital credentialing" is pretty well-used term as well
Dave Longley: "Decentralized Credentials" ?
Erik Anderson: I like that, it's ok
Manu Sporny: Yeah, that's ok
Erik Anderson: I have to drop off, another call
Manu Sporny: We'll send the new name to the mailing list to see if anyone objects
Manu Sporny: We had some spec changes, most recent change is the login mechanism that was just added

Topic: Decentralized Credentials-based Login

Manu Sporny: A commit was made yesterday to the "Decentralized Credentials" specification adding a Persona-like login mechanism: https://github.com/web-payments/web-payments.org/commit/e88f5717bb0a1496289bfae17312cfda34bdb468
Manu Sporny: The spec provides a way to assert facts about yourself, the same mechanism can be used for login, now that persona is on the backburner at mozilla, we're back to not really having a unified login mechanism other than OpenID connect, and while we could use Decentralized-Credentials-based login using OpenID connect, the flow is not ideal, the other issue with OpenID connect is that there are something like 17 specs you need to implement to get it working, it's not trivial to implement to do a login. Persona by comparison was fairly trivial to implement, especially if using secure messaging instead of the JOSE stack.
Manu Sporny: So what was added to DC spec was an example of login mechanism, so if you don't have openID or persona then you can still do a login, it's a fairly simple 2-step process
Manu Sporny: The other thing that this new login flow does is ... it can operate as a replacement for persona, it's a much more simplified version for persona, it also means there can be a browser polyfill for it, using a regular desktop, tablet, etc you can do an email-based login
Manu Sporny: Looks like this: customer goes to a store to make a purchase, type in/auto fill email, and if they have the browser implementation then they'll log right in. If they don't, then the polyfill will contact a 3rd party identity login service that looks just like Persona.
Manu Sporny: It's a fairly nice way of doing login, with one exception in that 3rd party app could find your ID using a decentralized protocol
Manu Sporny: We're looking at using telehash for the decentralized bits of it.
Manu Sporny: So all the identity providers don't have to be tied to a single third party
Manu Sporny: They just join a decentralized network
Manu Sporny: If you dont' have browser impl. then 3rd party network finds your ID provider and store talks to them and gets digitally signed ID+email (that credential)
Manu Sporny: Your credential could be stored on a completely different identity provider, etc. it's fairly complicated behind the scenes but the customer it just is a quick login with browser support or not.
Manu Sporny: What the store gets is a digitally-signed assertion that you have that email address, which is what persona does right now.
Manu Sporny: Since we're also talking about payments here, what we also want is to send your preferred payment provider to the store, so the credential will include verified email and payment provider
Manu Sporny: Other things in the future could include, email address, preferred payment provider, and shipping address when logging into amazon, for instance, etc
Manu Sporny: Dave Longley, we may want to talk a bit more about the telehash-based mechanism
David I. Lehn: Why are we considering telehash?
Dave Longley: At a high-level the telehash based mechanism - decentralized network - makes it easy to discover nodes on a decentralized network. Individual identity providers would generate a hash and join a network. Any queries that came across the network for various credentials would return which identity provider could provide the credentials. We want an authentication layer on top of this. [scribe assist by Manu Sporny]
Dave Longley: We need to think through the authentication layer a bit more. Basic idea is that authenticated requests for given email address. Other credentials could be used. Decentralized network would respond w/ which identity provider handles which email address. [scribe assist by Manu Sporny]
Dave Longley: If you have a browser implementation, it provides the login information directly. If you don't have a browser implementation, you ask the decentralized network. [scribe assist by Manu Sporny]
Manu Sporny: So, in general, you go to the store and put in your email address. That store calls navigator.id.login('email@example.org', 'http://example.com/login-callback'). In the browser-native implementation, that would create a dialog where the user picks which identity they want to use to login, the email credential verifying that you own the email address is retrieved from the identity provider, and the credential is delivered to the website.
Manu Sporny: In the non-browser-native implementation, the polyfill would open a browser window to a trusted, open source login aggregation site (jointly run by W3C, Mozilla, and IETF). That site would hook into the telehash protocol, retrieve your email-to-identity-provider mapping (protected via a password to prevent information leakage), and use that to map the email to the identity provider. The rest of the interaction would be the same as the browser-based mechanism above. Note that this step is done to ensure that the identity provider doesn't know where you're using each credential (tracking protection).
Dave Longley: We might be able to implement this where the store would just have a javascript telehash client, which just runs in your browser. Browser connects and gets your identity provider. [scribe assist by Manu Sporny]
Manu Sporny: There are of course, privacy issues w/ that approach - namely that each store would know who your identity providers are (and that's probably not a good thing).
Dave Longley: Since the telehash client is a javascript client, you can talk more closely with the browser. Maybe there is something clever we can do w/ the authentication there - leveraging Web Crypto for one-time pads. The information that you use is only in localstorage for that site. There are some implementation details that we need to think through, but that we can use a javascript telehash client means that we may be able to solve the privacy issues as well. [scribe assist by Manu Sporny]
Manu Sporny: We can always fall back to a 3rd party site to do the implementation, like Persona did.
Dave Longley: It is fully decentralized, but we provide a mechanism to ease implementation. [scribe assist by Manu Sporny]
Manu Sporny: We don't want identity providers to be able to track you across the web, there's a debate about whether or not that's ever possible, etc. evercookies, google tracking, etc.
Manu Sporny: However, that's another concern and we'll get to that in time. The solution is simpler than OpenID Connect and requires less of a technology stack (and infrastructure) than Persona.

Topic: HTTP Signatures

Manu Sporny: We've gotten good feedback from some folks working on HTTP/2 and HTTPbis
Manu Sporny: We've made updates based on mark nottingham and julian reschke's feedback
Dave Longley: We should also make sure to review this (looks more or less like what we ended up with): http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
Dave Longley: And this, which was abandoned: https://tools.ietf.org/html/draft-burke-content-signature-00
Manu Sporny: The other thing that's interesting with the signature stuff is that the Authorization header that is meant to be client-server, http is written such that the client and server can switch places, and that's perfectly fine, the problem is in including Authorization header in an http response
Dave Longley: I believe that Content-Signature might not be the right thing... maybe just "Signature" header? [scribe assist by Manu Sporny]
Manu Sporny: If we do that, should we have the Authorization header? [scribe assist by Manu Sporny]
Dave Longley: If we do that, we should abandon Authorization, or put it in another specification. [scribe assist by Manu Sporny]
Dave Longley: Maybe Authorization should be for sessions only? [scribe assist by Manu Sporny]
Manu Sporny: Maybe we'll put Authorization into a different spec, and Signature header into a different spec? Authorization builds off HTTP Signature Header spec? [scribe assist by Manu Sporny]
Dave Longley: That allows us to make a number of changes w/o breaking backwards compatibility. [scribe assist by Manu Sporny]
Dave Longley: If they're just using the Signature header, they're using the new mechanism. If they're using it in the old way, it either won't function or it won't be supported. [scribe assist by Manu Sporny]
Brent Shambaugh: Sorry that I did not make it to the beginning part of the teleconference. Did it go well?
Brent Shambaugh: I just posted thoughts to the list. It might be better there.
Manu Sporny: Yeah, posting to the mailing list is helpful, thanks.

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.