- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 07 Aug 2012 11:44:04 -0400
- 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:
http://payswarm.com/minutes/2012-07-24/
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
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2012Jul/0003.html
Topics:
1. Aligning of JSON Web Keys and Security Vocabulary
2. New payswarm.js release
3. Registering a new Web Key
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Manu Sporny, David I. Lehn
Audio:
http://payswarm.com/minutes/2012-07-24/audio.ogg
Dave Longley is scribing.
Manu Sporny: any updates or changes to the agenda before we
start?
Topic: Aligning of JSON Web Keys and Security Vocabulary
Manu Sporny:
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-00
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:
{"jwk":
Dave Longley: We were thinking of mapping that to a specific
term - like "sec:publicKey" [scribe assist by Manu Sporny]
David I. Lehn:
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04
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
Sporny]
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
Sporny]
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:
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-04
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
release
Manu Sporny: just today we updated the dev.payswarm.com website
Manu Sporny: Today we released a new version of -
https://dev.payswarm.com/
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 -
https://github.com/digitalbazaar/payswarm.js
Manu Sporny: if you look in some of the examples, specifically
Registering a new public key:
https://github.com/digitalbazaar/payswarm.js/blob/master/examples/register-new-key.js
Publishing an asset for sale:
https://github.com/digitalbazaar/payswarm.js/blob/master/examples/publish-asset-for-sale.js
Purchasing an asset:
https://github.com/digitalbazaar/payswarm.js/blob/master/examples/purchase-asset.js
Topic: Registering a new Web Key
Manu Sporny:
https://github.com/digitalbazaar/payswarm.js/blob/master/examples/register-new-key.js
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
program.
Manu Sporny:
https://github.com/digitalbazaar/payswarm.js/blob/master/examples/register-new-key.js#L90
Manu Sporny:
https://github.com/digitalbazaar/payswarm.js/blob/master/examples/register-new-key.js#L68
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
file
Manu Sporny: then we go out to the payswarm authority and get
its web keys endpoint
Manu Sporny: Web Keys endpoints URL:
https://dev.payswarm.com/.well-known/web-keys
Manu Sporny: the PA config is key-value pairs in JSON-LD with
endpoints
Dave Longley: If you include a callback and a nonce, you will
receive an encrypted response back. [scribe assist by Manu
Sporny]
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
Sporny]
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:
https://github.com/digitalbazaar/payswarm.js/blob/master/examples/register-new-key.js#L95
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
Sporny]
Manu Sporny: we're probably also put the payswarm endpoints into
.well-known
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
Sporny]
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
Sporny]
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?
http://manu.sporny.org/2012/mythical-differences/
Received on Tuesday, 7 August 2012 15:44:36 UTC