W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2012

Web Payments Telecon Minutes for 2012-07-24

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 07 Aug 2012 11:44:04 -0400
Message-ID: <502137C4.1000206@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
Thanks to Dave Longley for scribing the minutes for the telecon two
weeks ago. Sorry this email is so late, I forgot to send it out after
the call last time. The HTML minutes have been online for a while now:


Full text of the discussion follows for archival purposes at the W3C.
Audio of the meeting is available as well (link provided below).


Web Payments Community Group Telecon Minutes for 2012-07-24

   1. Aligning of JSON Web Keys and Security Vocabulary
   2. New payswarm.js release
   3. Registering a new Web Key
   Manu Sporny
   Dave Longley
   Dave Longley, Manu Sporny, David I. Lehn

Dave Longley is scribing.
Manu Sporny:  any updates or changes to the agenda before we

Topic: Aligning of JSON Web Keys and Security Vocabulary

Manu Sporny:
Manu Sporny: http://payswarm.com/specs/source/vocabs/security
Manu Sporny:  melvin, over the weekend, asked if there was going
   to be any aligning of these two specifications
Manu Sporny:  his question was whether if the jwk spec overlaps
   with the web keys spec, actually.
Manu Sporny:  after looking at the jwk spec in detail, we came to
   the conclusion that it's much closer to the security vocab spec
   than the web keys spec.
Manu Sporny:  the jwk spec is an ietf spec that describes how you
   express a public key and its parameters in json
Manu Sporny:  it's a purely a container mechanism/format
Manu Sporny:  it doesn't talk about registering keys, generating
   them, or signing with related private keys, it's just for
   expressing them in json
Manu Sporny:  the security vocab also does this but also provides
   other things in the vocabulary
Manu Sporny:  including signature parameters/how to express other
   PKI information
Manu Sporny:  the question is whether or not those two vocabs
   need to be merged or if they are doing different things, etc.
Dave Longley:  I do think we need to ensure that whatever is
   spec'd in JSON Web Keys do have properties in the Security
   Vocabulary. [scribe assist by Manu Sporny]
Dave Longley:  If people just want to use the JSON Web Keys spec,
   you can just add a "@context" via JSON-LD to that data to
   translate it to the Security Vocabulary easily. [scribe assist by
   Manu Sporny]
Manu Sporny:  so your suggestion is to use Json-ld to map jwk to
   the security vocab?
Dave Longley:  Yeah, I think that woudl be fine if people opt to
   continue using JWK. We can try to align it as much as needed, but
   since JSON-LD allows the easy mapping, they're mostly compatible
   now. [scribe assist by Manu Sporny]
David I. Lehn:  are you sure that they are really compatible?
David I. Lehn:  if you are using simple strings for algorithms
   and we're using urls then we could have compatibility issues
Manu Sporny:  we could create/change the vocabulary to take
   strings or URLs to deal with that
Manu Sporny:  for example, let's say that the value is either a
   URL or a base64-encoded PEM value ... an application could easily
   tell the difference
Manu Sporny:  so the application interacting with the vocab could
   handle it
Manu Sporny:  so even without perfect compatibility there's a way
   around it, we just have to make sure that the jwk vocab works
   with the security vocab
Manu Sporny:  lehn, have you looked and seen any conflicts?
David I. Lehn:  not in detail, but the algorithm property looked
   like it could be an issue
Manu Sporny:  the way we express an algorithm in the security
   vocab now is a string
Manu Sporny:  and the way the jwk spec does is a little different
   (at least with what they have specified)
Manu Sporny: "alg":"EC", "crv":"P-256"
Manu Sporny: we do this instead: "aes-128-cbc"
Dave Longley:  Also, we only have certain things specified. We
   only have the algorithms specified that allow us to do the
   PaySwarm work. [scribe assist by Manu Sporny]
Dave Longley:  We could use the same strings that OpenSSL uses...
   [scribe assist by Manu Sporny]
Manu Sporny:  the other concern is making it too heavy-weight, we
   didn't want to support what we didn't have to at the moment
Manu Sporny:  but if we're going to make it complete, we'll have
   to add a lot of these algorithm possibilities in there
Manu Sporny: One way to tell if it's a JWK or not is this:
Dave Longley:  We were thinking of mapping that to a specific
   term - like "sec:publicKey" [scribe assist by Manu Sporny]
David I. Lehn:
David I. Lehn:  there's a general issue with these json pki
   specs, we may want to try and align with them
Manu Sporny:  the concern i have is that this is like a kitchen
   sink issue, defining absolutely everything
David I. Lehn:  we're doing that too, but we're looking at it
   from a linked data view
Dave Longley:  I think it's important to not that we're going at
   this from a more flexible approach - we are taking the Linked
   Data approach... a graph can be structured in JSON in multiple
   different ways, with JSON-LD it doesn't matter where you put the
   info, just that the info is there in the graph. [scribe assist by
   Manu Sporny]
Dave Longley:  So, you don't need every app to work with the data
   in the same way. The approach that JWE takes doesn't take a
   Linked Data approach or a flexible graph approach - they say the
   data "has to look this way" - and that's not as flexible. [scribe
   assist by Manu Sporny]
Dave Longley:  Because we're using Linked Data, it makes it
   easier to translate the JWK/JWE stuff to the Security
   Vocabulary... the inverse is not possible. [scribe assist by Manu
Dave Longley:  The only real incompatibility is the values of the
   properties... we can always map the properties into the Security
   Vocabulary - the Web Keys specs can take JWK as input if it has
   an appropriate context and map it to the Security Vocabulary.
   [scribe assist by Manu Sporny]
Dave Longley:  There may be minor translations that have to be
   done. The Web Keys spec should hopefully be able to take JWK
   input if you wanted to register JWK keys. Just send the JWK key
   up with the appropriate context and you're good. [scribe assist
   by Manu Sporny]
Manu Sporny:  yes, and the web keys spec mostly just reuses PEM
   which most crypto tools have.
Dave Longley:  Yeah, any crypto lib has support for ASN.1 and PEM
   - if you don't have it, getting from ASN to PEM is pretty easy.
   You just take what's DER encoded and base-64 encode that adding
   headers where appropriate. Most everyone can do base-64. If you
   do crypto, you're going to have ASN data. [scribe assist by Manu
Dave Longley:  Almost all of the tools have some way to
   read/write PEM. [scribe assist by Manu Sporny]
Manu Sporny:  this came up a few years ago with some other work
   (webid?) and our position has always been that crypto tools have
   PEM support
Manu Sporny:  vs. having to construct the key from its basic
   bignum components, etc.
Dave Longley:  Yeah, having to take key compontents and having to
   turn them into keys is much harder than feeding PEM to these
   libs. [scribe assist by Manu Sporny]
Dave Longley:  Most people don't even understand that keys break
   down into those components. [scribe assist by Manu Sporny]
Manu Sporny:  so before we go ahead and try to incorporate
   jwk/etc into the security vocabulary is probably a bit premature
   until we see it being used quite a bit
Manu Sporny:  right now we want to specify the bare minimum
Manu Sporny:  we can always add jwk parameters to the security
   vocabulary in the future as needed
David I. Lehn:
Dave Longley:  Looks like they've removed some of the more
   specific strings [scribe assist by Manu Sporny]
Manu Sporny:  it seems like we just need to talk to m. jones and
   see if there's a way to cooperate
Manu Sporny:  it could be that we're just doing completely
   different things
Manu Sporny:  they aren't doing any linked data stuff, it's just
   pure json
Manu Sporny:  anything else before moving on?

Topic: New payswarm.js release

Manu Sporny:  let's talk briefly about the new payswarm.js
Manu Sporny:  just today we updated the dev.payswarm.com website
Manu Sporny: Today we released a new version of -
Manu Sporny:  one of the features that we released here is the
   ability to interface with the rest API, which uses JSON-LD
Manu Sporny: Github code for payswarm.js -
Manu Sporny:  if you look in some of the examples, specifically
Registering a new public key:

Publishing an asset for sale:

Purchasing an asset:


Topic: Registering a new Web Key

Manu Sporny:

Manu Sporny:  we created these examples to see if they work the
   way developers would like to use them and to ensure ease of use
Manu Sporny:  all of the code uses the payswarm client javascript
   library, which is under a BSD 3-clause license
Manu Sporny: Steps to register a new Web Key:
Manu Sporny: 1. Generate a public/private keypair (or use an
   existing one).
Manu Sporny: 2. Fetch the Web Keys registration endpoint from the
   PaySwarm Authority.
Manu Sporny: 3. Generate the key registration URL and go to it in
   a browser.
Manu Sporny: 4. Get the new key information and provide it to the
Manu Sporny:

Manu Sporny:

Manu Sporny:  we start by reading from a config file that will
   store the keys
Manu Sporny:  we generate keys if there aren't any in the config
Manu Sporny:  then we go out to the payswarm authority and get
   its web keys endpoint
Manu Sporny: Web Keys endpoints URL:
Manu Sporny:  the PA config is key-value pairs in JSON-LD with
Dave Longley:  If you include a callback and a nonce, you will
   receive an encrypted response back. [scribe assist by Manu
Dave Longley:  There is another issue too - if they're using a
   web browser, they may be communicating w/ an insecure site - so
   the response must be encrypted. [scribe assist by Manu Sporny]
Dave Longley:  Most wordpress installations are served over http
   - we have to make sure that people don't get that registration
   information back over an insecure channel. It's not a big deal w/
   key registration, but there are other callbacks that you don't
   want to go over an insecure channel. [scribe assist by Manu
Dave Longley:  Also, vendors can register and set certain
   preferences that we don't want to be exposed via clear text over
   the Web. [scribe assist by Manu Sporny]
Manu Sporny:  also keep in mind that the only people that have to
   do this sort of stuff is developers
Manu Sporny:  other people will use a web interface where they
   don't have to see any messy details
Manu Sporny:

Dave Longley:  Yeah, we just need to provide an options object to
   the call to create the registration URL. The part that fetches
   the endpoints wasn't in there yet, but much of it can be cleaned
   up now that we have the endpoints URL. [scribe assist by Manu
Manu Sporny:  we're probably also put the payswarm endpoints into
Dave Longley:  yes
David I. Lehn:  yes
Manu Sporny:  one question is whether or not we should combine
   .well-known payswarm+webkeys to reduce # of requests
David I. Lehn:  two files sounds fine to me, (separate)
David I. Lehn:  we just need to ensure caching is set up properly
Manu Sporny:  so we'll keep them separate
Manu Sporny:  when you send up the request to register your key,
   the PA will generate a URL for you for the key
Manu Sporny:  which can be used later for revocation and for
   identifying the key in signatures
Manu Sporny:  other information like who owns the key will also
   be registered with it
Manu Sporny:  you'll need to be logged into the PA's website to
   accomplish this
Manu Sporny:  you take the generated registration url and paste
   it into your browser
   ... and then take the encrypted message that is returned in
   the browser and paste it back into the example
   ... and then the payswarm.js library is used to decrypt the
   message and confirm that the public key was registered
Manu Sporny:  then the local config is updated
Manu Sporny:  and that's about it for registering a public key
Dave Longley:  Other than simplifications in the payswarm.js API,
   I think we're fine. If you gloss over some of the messier
   "configuration" details. [scribe assist by Manu Sporny]
Dave Longley:  The process is pretty simple now, yes. [scribe
   assist by Manu Sporny]
Manu Sporny:  Any way we could simplify this? [scribe assist by
   Manu Sporny]
Dave Longley:  We could remove encryption of the response
   message? That doesn't help the UX any, though... they don't care
   about the data. [scribe assist by Manu Sporny]
Dave Longley:  If you're using a browser, it's even easier since
   you don't have to cut/paste. [scribe assist by Manu Sporny]
Manu Sporny:  The PHP code is a bit more involved... mostly
   because it's assumption that you're on the Web. [scribe assist by
   Manu Sporny]
Dave Longley:  The PHP stuff is a bit less flexible than the
   JavaScript stuff - so, it's just a little more flexible - store
   it however you want (or don't store it). [scribe assist by Manu
Dave Longley:  You could write a node.js app that stores it in a
   database, so it's more flexible. [scribe assist by Manu Sporny]
Manu Sporny:  Do we want to align the payswarm.js code with the
   payswarm-php code? [scribe assist by Manu Sporny]
Dave Longley:  If we do, we'd align with the JavaScript code...
   it's more flexible. [scribe assist by Manu Sporny]
Dave Longley:  The PHP code relies more on hooks - you have to
   implement hooks and everything works. [scribe assist by Manu
Dave Longley:  The JavaScript stuff uses options to convey the
   data that needs to be used during the process. [scribe assist by
   Manu Sporny]
Manu Sporny:  So, do we use hooks and options? [scribe assist by
   Manu Sporny]
Dave Longley:  There are only a few modules that would use the
   PHP stuff, not much need for customization there - we could add
   options, but the hooks seem to be working well for now. Not that
   big of a deal right now. [scribe assist by Manu Sporny]
Dave Longley:  We also need to write one of these in Python...
   I'd imagine the JavaScript and Python versions would look pretty
   similar. [scribe assist by Manu Sporny]
Manu Sporny:  it seems like the for the most basic stuff the
   thing that needs to work is the JSON-LD processing
Manu Sporny:  that and cryptography
Manu Sporny:  there are only a handful of methods that are needed
   to register keys, list items for sale, and purchase
Manu Sporny:  We're taking all the hooks out of payswarm.js,
   right? [scribe assist by Manu Sporny]
Dave Longley:  Yeah, we're taking out all the hooks... then it's
   just straight port to Python. [scribe assist by Manu Sporny]
Dave Longley:  Yeah, the hooks are only in there because of PHP -
   the hooks should probably be built on top of the basic
   options-based framework... then build the PHP hooks on top of
   that. It'll end up working the same way that it does now, so it
   should be pretty transparent to developers. [scribe assist by
   Manu Sporny]
Manu Sporny:  we're at the top of the hour
Manu Sporny:  so we'll push off listing and purchasing assets to
   the next call.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
Received on Tuesday, 7 August 2012 15:44:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:21 UTC