Re: Web Payments Telecon Minutes for 2014-04-30

On 30 April 2014 18:53, <msporny@digitalbazaar.com> wrote:

> 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.
>
>
>
>
>
I'd like to try and signatureAlgorithm to use for crypto currencies.  So
far I have invented:

"https://w3id.org/security#signatureAlgorithm": "ecdsa-secp256k1"

I dont think this is correct.

During this telcon there were a number of registries mentioned:

XML Dsig
OpenSSL
XMPP
JOSE
W3C Crypto

Are more?

Not sure the way forward here.  Should we compile a list, say, in the wiki
and then work out which to reuse or a common subset?

It would be good if I nail down which string to use, at least in the short
term.