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
Audio Log
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: 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: 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
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

Topic: Registering a new Web Key

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: 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
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.

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