Web Payments Community Group Telecon

Minutes for 2014-04-30

Dave Longley is scribing.
Manu Sporny: We had a request to add something to the agenda; Tim Holborn wanted to add something about gathering user stories, but unfortunately, it's the middle of the night where he is, but maybe we could talk about his request at a very high level before we talk about the use cases.

Topic: Graph Signatures Vocabulary

Manu Sporny: Melvin raised a question on the mailing list a while ago.
Manu Sporny: He needs to be able to digitally-sign some information in a different way, specifically, he wants to use an ECDSA-256 curve key to digitally sign JSON-LD information, and he thought he could just use the GraphSignature2012, but the spec for that assumes that you're using RSA and he wants to use different parameters for the signature
Manu Sporny: The nice thing about the spec is that it lets you use a different signature mechanism, but he was wondering how to specify the parameters as Linked Data.
Manu Sporny: So we were wondering if we should have a different vocabulary for signatures
Manu Sporny: That's the open question
Dave Longley: We should probably have this in a different vocabulary, we could keep the security vocab a little cleaner if we did that. [scribe assist by Manu Sporny]
Dave Longley: Of course, we would like to minimize the number of signature mechanisms, so that implementations aren't complicated. [scribe assist by Manu Sporny]
Manu Sporny: The URL might change. [scribe assist by Manu Sporny]
Manu Sporny: Which would break backwards compatability. [scribe assist by Manu Sporny]
Manu Sporny: This would affect the URL for the graph signature would change
Dave Longley: We could keep it in the security spec for backwards compatability. [scribe assist by Manu Sporny]
Manu Sporny: We have some deployment with GraphSignature2012, but it's not too much of a big deal
Manu Sporny: Melvin's system is highly experimental, so the question is whether or not we should put highly experimental things into here... so should we add things to the signature vocabulary as people need them
Manu Sporny: Or only add if they are standards track
Dave Longley: For experimental things, you can always use the full URL - you could invent names or a prefix for it. It doesn't have to go in the official document, but the implementations would work if they understood the URL for the specific type of signature that's being created. That's probably the way we should go with that. [scribe assist by Manu Sporny]
Manu Sporny: So, use the full URL for now? [scribe assist by Manu Sporny]
Dave Longley: We should probably not put it into the official spec if it's still experimental. Melvin should probably just use a full URL. [scribe assist by Manu Sporny]
Dave Longley: He can use whatever he wants for the URL, and it probably shouldn't point to the signature algorithms vocabulary. [scribe assist by Manu Sporny]
Manu Sporny: So, should we create it? [scribe assist by Manu Sporny]
David I. Lehn: Does IETF specify all of the things we need for this?
David I. Lehn: They have URNs for them?
Melvin Carvalho: Sounds good to me :)
Manu Sporny: I think they just have a registry, i don't think i saw that the last time i looked, we need a URL
David I. Lehn: Out of curiosity, does the IETF thing specify the algorithms already? [scribe assist by Manu Sporny]
Manu Sporny: If they have it we should use it
Melvin Carvalho: Yes, my system is experimental ... ill be testing over the next year i think
Melvin Carvalho: Openssl specifies a list of algorithms iirc
Manu Sporny: If the IETF spec specifies URLs or URNs we should use them, we need an identifier
Manu Sporny: We should create a signatures vocab for these
Manu Sporny: For now it will just have two entries, it won't take long to set up and start using
Manu Sporny: Any other thoughts on that?
Brent Shambaugh: There are bitcoin URIs defined somewhere
Manu Sporny: If you're talking about bitcoin URIs for a particular type of signature we can use that, otherwise it may just have more to do with specific URIs for bitcoin
Dave Longley: Yeah, these are URIs for bitcoin addresses
David I. Lehn: Short strings there
Manu Sporny: Yeah, so that's the problem, the JOSE spec just uses strings
David I. Lehn: I thought the xmpp people has a URN scheme too, but i can't find the reference right now
Manu Sporny: Here's how we'd probably do it, we'd specify the URLs in the signature vocabulary and point to the JOSE spec to indicate that's what we're talking about
Manu Sporny: For example, The MelvinSignature2014 algorithm uses the ES256 algorithm as defined here: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#appendix-A.1
Manu Sporny: I think we did that in a couple of other specs, does that sound like an acceptable plan?
Melvin Carvalho: Web crypto API also has a list of algorithms
Manu Sporny: Problem w/ Web Crypto API is that none of them are URLs. XML DSIG does have URLs, that's what we use right now. ok, we can just use those XML DSIG URLs maybe ... if everything we need is there
Manu Sporny: The WebCrypto API isn't a recommendation yet, so it may be problematic to point at it
Manu Sporny: Any concerns about the plan?
No concerns expressed by the group.
Manu Sporny: Ok, moving on

Topic: Tim Holborn Request for User Stories

Manu Sporny: On the mailing list, Tim said he thinks we need some user stories... the question i have is "What's the difference between a user story and a use case"
Manu Sporny: The use cases are a single line summary of a user story
Manu Sporny: Once we figure out each use case we'll have a 1-2 paragraph user story to expand upon the one liner.
Manu Sporny: With the use cases we have today, we want to decide if we believe they are in/out of scope, then we'd hand them off to as many people as we can in the Web Payments CG to write a 1-2 paragraph story about what the motivation for the use case is
Brent Shambaugh: https://web-payments.org/specs/source/use-cases/ <--- i.e. Lars and Jude?
Manu Sporny: I think that's what we're shooting for and that's at the top there
Manu Sporny: Any other thoughts on that?
Dave Longley: That's a generic user story, a more detailed representation of the use case. It makes it more obvious about what we're trying to support. [scribe assist by Manu Sporny]
Dave Longley: He could have said that he wants "authentic" use cases, but that's what we have now, we've got use cases from humans so I think we want to do what Tim's suggesting. [scribe assist by Manu Sporny]
Brent Shambaugh: What does he mean by "engagement by what webwewant.org?"
Timothy Holborn: Hey guys, I just got pinged about this, joining the call via IRC.
Manu Sporny: "Webwewant.org" is about making the web about a fundamental human right, etc. and the question is how we'd take that movement and direct it at this web payments stuff, but i think tim would have to propose something there, the user stories are elaborations of each use case, etc.
Timothy Holborn: My concern was that some members may not have enough software development lifecycle / related experience to consider all the facets relating to a use-case.
Timothy Holborn: Therein; the use-stories (meaning, their more contextual) might help flesh that out, and find things we might be missing
Timothy Holborn: So, your in the US, others in other ‘common-law’ countries
Manu Sporny: So i think Tim is agreeing, he wants us to spell out what each use case means and get more input from local groups around the world.
Timothy Holborn: So many different ‘local rules’ to things.
Manu Sporny: From non-US/other localities that we don't have a lot of input from today
Timothy Holborn: Re: human rights = web - so is the ability to monitise work. I think we want to encourage accessibility for ‘value-adding’ via WWW…
Timothy Holborn: I was lucky to get a 60k projector out of customs in UAE, I found out about some local taxes along the way, etc.
Manu Sporny: Yes, that's true (what tim said), does anyone thing we haven't addressed tim's concerns with the user story stuff?
Manu Sporny: The current plan is to take the use cases (the one liners) and expand them out into 1-2 paragraph user stories, once we've decided which use cases are in/out of scope
Manu Sporny: And it will be an iterative cycle, and the hope here is that multiple people on the mailing list will be writing user stories based on the use cases
Timothy Holborn: We’ve got a fair bit on our plate atm. any of these process also have threats about becoming insular with the concepts / language, etc. by going out and seeking info from related groups - we might come across new concepts / ideas / issues… gives us an administrative challenge.
Timothy Holborn: Broader community engagement

Topic: Organizing Web Payments Workshop Use Cases

Manu Sporny: How do we want to approach culling the use cases down to a manageable set? What we could do is talk about each one and give it a thumbs up/down, just go through the list like that, see where the discussion takes us.
Manu Sporny: We're trying to aggressively cull these down to a basic set for the Web Payments IG.
Timothy Holborn: I think that’s a very important attitude to have.
Dave Longley: So long as we’ve got sufficient datapoints, to understand what our requirements need to be. [scribe assist by Timothy Holborn]
Dave Longley: So we're just doing another iteration on categorization?
Manu Sporny: The first use case: "Personal vault/wallet can host information/assets and issue ids useful for various things (e.g. payments?)"
Manu Sporny: Note, the first iteration would probably only store basic identity credentials and payment provider information
Manu Sporny: I think we should assume Identity is in scope unless the Payments IG decides otherwise
Manu Sporny: So we need to understand what needs to happen with Identity to make payments work on the Web'
Manu Sporny: Kumar from mozilla is asserting that we don't need to touch Identity at all for payments on the web
Manu Sporny: And that's correct, but it means we don't really add much value, you can't tie payments to identity without any standard
Timothy Holborn: RWW / http://www.w3.org/DesignIssues/CloudStorage.html are producing potential “cloud storage” services. i imagine interactions will play-out between the groups.
Manu Sporny: Tim, yes - this is in that same vein. Payments are fundamentally about trust between two entities, and in order to do a payment on the web, since you aren't face to face, you need to be able to understand who the sending/receiving parties are, if for no other reason for KYC and anti-money laundering for banks
Timothy Holborn: KYC / AML can be done by activating an account (which can be done via a banking interface, paying to set-up an account, for example).
Manu Sporny: That's mainly why identity is big for payments, but identity is also big on the web in general (single sign on for the web, etc. the education space also needs an identity mechanism and a way to store personal information in the cloud in a way that is under your control ... and that's all about identity)
Timothy Holborn: Once that account is created however; the online account needs to maintain trust
Brent Shambaugh: What about anonymous payments?
Timothy Holborn: I see these as two seperate issues.
Manu Sporny: We do want to support anonymous payments, but in a lot of cases that won't work
Manu Sporny: Due to various regulations, etc.
Manu Sporny: Banks can't enable money laundering --- anonymous for small payments can work, but not for large payments based on current regulation, etc.
Manu Sporny: But the anonymity and privacy are part of the identity discussion
Timothy Holborn: Could support anon in terms of what the receiver sees
Manu Sporny: We want to maximize those things where transactions don't require it
Brent Shambaugh: Could you have an anonymous URI and not attribute things to anyone?
Manu Sporny: Yeah, you could share URLs between like a thousand people, you could create anonymous URLs, you can't tie them to a particular person, but have information associated with it like age of the person so you know they can buy things/meet certain regulations
Manu Sporny: There are varying degrees that we want to support here that are all part of the identity discusison
Manu Sporny: Re: tim in IRC, we do want to support anonymity w/respect to what the receiver sees as much as possible
Manu Sporny: Keeping your details private from the merchant where they don't need that information, etc.
Brent Shambaugh: Yeah, today you give people your credit card number and that's not good
Manu Sporny: Yes, especially with a debit card
Timothy Holborn: One of the KYC / AML technologies i work with http://www.isignthis.com/ can identify a person rather well, rather quickly.
Timothy Holborn: That gets past the reg. issues.
Dave Longley: First use case should be changed, it's too high level, it should be narrowed. [scribe assist by Manu Sporny]
Timothy Holborn: However; in a use-case, where a provider like that is used; to do the authorisation for an online ‘crediential’ how is that ‘crediential’ tied to the user on an on-going basis, if the transactions relate to say - a crypto-currency, or a e-contract - something that doesnt require another ‘get’ request from a traditional banking account.
Manu Sporny: So, the use case should become something like: "Store basic identity credentials and payment provider information on the Web in a way that is easy to share with various merchants given authorization by the owner of the identity, and that is easy to synchronize between devices." [scribe assist by Manu Sporny]
Manu Sporny: Basically, a read-write web storage mechanism. [scribe assist by Manu Sporny]
Dave Longley: One way to look at these Identity use cases is through the lens of Initiating Payments or Digital Receipts -- if it's related to that, it's likely in scope.
Dave Longley: So, meeting this use case is required given that you'd need something like it to initiate a payment. If you're storing digital receipts with your identity, that requirement would make this use case in scope as well. Obviously, supporting this will have applicability to use cases outside of payments. [scribe assist by Manu Sporny]
Dave Longley: We clearly need to support this use case because it makes the whole initiating payment and digital receipts use cases easier to achieve. [scribe assist by Manu Sporny]
PROPOSAL: Accept the following use case - "Store basic identity credentials and payment provider information on the Web in a way that is easy to share with various merchants given authorization by the owner of the identity, and that is easy to synchronize between devices."
Dave Longley: +1
Manu Sporny: +1
David I. Lehn: +1
Brent Shambaugh: +1
Timothy Holborn: +1
RESOLUTION: Accept the following use case: Store basic identity credentials and payment provider information on the Web in a way that is easy to share with various merchants given authorization by the owner of the identity, and that is easy to synchronize between devices.
USE CASE: Store basic identity credentials and payment provider information on the Web in a way that is easy to share with various merchants given authorization by the owner of the identity, and that is easy to synchronize between devices.
Manu Sporny: Looking at the second use case under identity - "Managed access to personal identity/attributes as economically valuable assets in a payment system"
Manu Sporny: Noting that the first iteration would probably not focus on the "economically valuable" dimension of the personal identity attributes
Dave Longley: I don't see the difference between this use case and the previous one. It's just the ability to manage whatever credentials that you have. [scribe assist by Manu Sporny]
Manu Sporny: Suggest that we strike this use case since it's covered by the previous one. [scribe assist by Manu Sporny]
Timothy Holborn: +1
Timothy Holborn: Add it as a note to the first one
Brent Shambaugh: What is "economically valuable"?
Manu Sporny: "Economically valuable" means that storing something like your spending habits would be valuable to someone like Walmart -- and you could potentially have the ability to be able to sell that information to them, etc.
Timothy Holborn: Birth certificate, passport, contract, important email,
Manu Sporny: We should be able to build that use case on top of what we have
Brent Shambaugh: +1
Brent Shambaugh: But it's not required now
Timothy Holborn: Perhaps an ontological method to assert something has a value. bit like creative commons,
PROPOSAL: Fold the second identity use case ("Managed access to personal identity/attributes as economically valuable assets in a payment system") into the first one, since it consists of largely duplicated information. Do not attempt to address "sale of personal information" in the first iteration of the technology, but keep it in mind while designing the core architecture.
Dave Longley: +1
Manu Sporny: +1
Timothy Holborn: +1
David I. Lehn: +0.5
Brent Shambaugh: +0.9
RESOLUTION: Fold the second identity use case ("Managed access to personal identity/attributes as economically valuable assets in a payment system") into the first one, since it consists of largely duplicated information. Do not attempt to address "sale of personal information" in the first iteration of the technology, but keep it in mind while designing the core architecture.
Timothy Holborn: I think it should be noted in relation to the first use-case that it is the intention of that use-case, to support both
Manu Sporny: As we approve use cases we should throw each approved one to the mailing list to have someone write a user story on the mailing list for each one
Manu Sporny: Once the user story is written we can integrate into the use cases document so there's a steady stream of updating the use cases.
Manu Sporny: Anything else before we go?
No other business, meeting adjourned.

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