- From: <msporny@digitalbazaar.com>
- Date: Wed, 30 Apr 2014 12:53:44 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes
for this week's Web Payments telecon are now available:
https://web-payments.org/minutes/2014-04-30/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2014-04-30
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0195.html
Topics:
1. Graph Signatures Vocabulary
2. Tim Holborn Request for User Stories
3. Organizing Web Payments Workshop Use Cases
Resolutions:
1. 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.
2. 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.
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Manu Sporny, David I. Lehn, Melvin Carvalho, Brent
Shambaugh, Timothy Holborn
Audio:
https://web-payments.org/minutes/2014-04-30/audio.ogg
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:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0109.html
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
Brent Shambaugh:
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/?viewmonth=201403&viewday=6
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
https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki
Brent Shambaugh: https://en.bitcoin.it/wiki/BIP_0021
Dave Longley: Yeah, these are URIs for bitcoin addresses
David I. Lehn:
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25
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
Melvin Carvalho:
http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#algorithms
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:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0197.html
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: This is a user story:
https://web-payments.org/specs/source/use-cases/#simple-payment-links
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:
https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
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: See
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0185.html
Timothy Holborn: I think that’s a very important attitude to
have.
Brent Shambaugh: Also:
http://www.supplydemand.info/webpayments/Web_Payments_Use_Cases_Refactoring_2014_04_25.html
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: Yes, let's start here -
https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Identity
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.
Manu Sporny:
https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Identity
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.
Received on Wednesday, 30 April 2014 16:54:07 UTC