Web Payments Community Group Telecon

Minutes for 2013-08-21

  1. Updates from Bitcoin Community
  2. Update from Mozilla Payments Meeting
  3. Update on GSoC Student Progress
  4. Secure Messaging vs. Javascript Object Signing and Encryption
  5. JSON Web Algorithms (JWA)
  6. JSON-LD Advantages over JSON
  7. JSON Web Key (JWK)
  8. JSON Web Tokens (JWT) vs. Secure Messaging
  9. JSON Web Encryption (JWE) vs. Secure Messaging
Manu Sporny
Dave Longley
Dave Longley, Manu Sporny, Kumar McMillan, Andrei Oprea, David I. Lehn, Brent Shambaugh
Audio Log
Dave Longley is scribing.
Manu Sporny: Our agenda today is an update on project statuses in Bitcoin, Mozilla payments, GSoC, and then on to the analysis of Secure Messaging vs. JOSE encryption and digital signature stacks. [scribe assist by Manu Sporny]

Topic: Updates from Bitcoin Community

Manu Sporny: i've been talking to a number of people in the Bitocin community and at the Bitcoin foundation
Manu Sporny: i've been talking to the education subgroup there, they're are trying to legitimize bitcoin. General community is trying to take on regulatory hurdles, etc., there's a lot of movement in the bitcoin community you just can't really see it, they are fairly insular, they are very focused on the bitcoin community not the larger web or how to get this integrated into the browsers, etc, but the people i've been speaking to have been very interested in trying to get bitcoin into the browser
Manu Sporny: Been talking to several CEOs of bitcoin companies, people doing processing of bitcoins, bitcoin developers, a nice representation of the full spectrum of what's needed to make Bitcoin viable long-term.
Manu Sporny: about 30% of those I'm speaking to are dabbling in bitcoin but very interested in the web payments work
Manu Sporny: the inside bitcoin conference led to a lot of good press and got them informed on what we're doing here. I'm getting a lot of private emails and having a number of private conversations with people who want to join in the work here

Topic: Update from Mozilla Payments Meeting

Kumar McMillan: Basically a meeting to focus on FirefoxOS payments implementation for Firefox Marketplace. [scribe assist by Manu Sporny]
Kumar McMillan: Very much focused on short term stuff that we're doing - expanding to some new payment providers, Latin America, what it means for our own system wrt. multiple backends. Not anything more than that. If you're in one country, we need to use a different operator billing method, stuff like that. [scribe assist by Manu Sporny]
Kumar McMillan: Focused on our product, UX review. Since we had engineers and designers in the same room, not a lot to report. What's interesting to this group is API related stuff, we didn't focus on that that much. [scribe assist by Manu Sporny]
Kumar McMillan: More people at Mozilla are now looped in on what we're doing here in the Web Payments group, not a lot to share right now, but might have some changes coming down the pipeline when they develop. [scribe assist by Manu Sporny]
Manu Sporny: we've been put in touch with the folks at the open badges work at mozilla (chris macavoy)
Manu Sporny: they said they were interested in JSON-LD and the digital signatures stuff, and i think you may have been the one that prompted them to start thinking about it
Manu Sporny: i've got a call with them later today about all this
Manu Sporny: i've been talking to the identity people about signatures as well
Manu Sporny: but they are a bit busy at the moment

Topic: Update on GSoC Student Progress

Manu Sporny: any updates andrei?
Andrei Oprea: The demo is ready to go online now. I'm going to start tracking my progress via github issues. I need to allow modifying the assets. Have the assets resigned. [scribe assist by Manu Sporny]
Andrei Oprea: I have some things to fix with sessions and cookies. [scribe assist by Manu Sporny]
Andrei Oprea: When you get the callback from the marketplace, I need to update stuff. [scribe assist by Manu Sporny]
Manu Sporny: we'll get you setup on a VM here. [scribe assist by Manu Sporny]
Andrei Oprea: Sounds good, once a day updates would be good. [scribe assist by Manu Sporny]

Topic: Secure Messaging vs. Javascript Object Signing and Encryption

Manu Sporny: i tried to be as thorough as i could, outlining all the things that i think are issues with the JOSE spec and the advantages Secure Messaging/HTTP Keys spec gives us
Manu Sporny: so this is a discussion about where the web commerce api should go
Manu Sporny: do we want to continue using the jwk/signature stuff or go with the JSON-LD signature stuff
Manu Sporny: so the conversation has a bit to do with JSON-LD and we've been talking about moving closer to using JSON-LD at least by using URLs in the data/messages, etc.
Manu Sporny: is there any particular way to go through this, top-down through the blog post or do you want to discuss particular things?
Kumar McMillan: no preference from me, just looking back over the post
Kumar McMillan: my main summary is that i just had some questions about the signature/encryption algorithms and those were answered and i just liked the advantages that JSON-LD provides around URLs there are definitely concrete problems in the current implementation that JSON-LD solves
Kumar McMillan: it would be helpful for other people on the call to go through

Topic: JSON Web Algorithms (JWA)

Manu Sporny: the main difference between --- at a very high level i think the JOSE group is trying to create a flexible way of expressing cryptography parameters and the use of them in JSON, it's kind of the kitchen sink approach, to support everything in common use today, which is one approach
Manu Sporny: the other major approach is what the Secure Messaging spec does
Manu Sporny: it tries to boil everything that's out there down to best practices
Manu Sporny: while also understanding that those will have to change in the future
Manu Sporny: cryptography is a constant battle of creating schemes that get broken and creating new ones
Manu Sporny: whatever we're doing now will be broken in a few years
Manu Sporny: we're trying to balance that against implementation complexity
Manu Sporny: one of the things with JWT and the JOSE stack is that it requires you to implement quite a few cryptographic mechanisms, which isn't too technically difficult, dave longley has implemented a crypto suite in javascript in http://github.com/digitalbazaar/forge, it has pkcs, symmetric, asymmetric crypto, etc. it takes a lot of time and expertise
Manu Sporny: we don't want to push off a lot of this complexity to implementers because the more there is, the more you have to implement, the more complexity, etc.
Manu Sporny: rather than us just saying you need this hash and this digital signature type
Manu Sporny: and leaving it at that, so the main difference is that the Secure Messaging stack tries to be simpler in providing best practices while still allowing algorithmic agility for switching in the future
Manu Sporny: the JOSE stack does the kitchen sink approach and so there's a lot of complexity all at once

Topic: JSON-LD Advantages over JSON

Manu Sporny: Advantages for JSON-LD:
Manu Sporny: A universal identifier mechanism for JSON objects via the use of URLs.
Manu Sporny: A way to disambiguate JSON keys shared among different JSON documents by mapping them to URLs via a context.
Manu Sporny: A standard mechanism in which a value in a JSON object may refer to a JSON object on a different document or site on the Web.
Manu Sporny: A way to associate datatypes with values such as dates and times.
Manu Sporny: The ability to annotate strings with their language. For example, the word ‘chat’ means something different in English and French and it helps to know which language was used when expressing the text.
Manu Sporny: A facility to express one or more directed graphs, such as a social network, in a single document. Graphs are the native data structure of the Web.
Manu Sporny: A standard way to map external JSON application data to your application data domain.
Manu Sporny: A deterministic way to generate a hash on JSON data, which is helpful when attempting to figure out if two data sources are expressing the same information.
Manu Sporny: A standard way to digitally sign JSON data.
Manu Sporny: A deterministic way to merge JSON data from multiple data sources.
Manu Sporny: an asset being combined with a listing from two separate sites and combining them together is something that JSON-LD can do natively
Manu Sporny: you can convert JSON documents and apply compaction/expansion and get data into a format your application will understand, so you don't have to write code to map things by hand
Manu Sporny: if someone publishes a JSON-LD context for twitter and someone publishes a context for the activity streams work, then converting from one to the other is a matter of a API calls
Dave Longley: To clarify - to map one thing to another, it's just an API call. [scribe assist by Manu Sporny]
Manu Sporny: JSON-LD provides ways to transform data to get it into a format you want that people have found useful
Manu Sporny: compaction, expansion, flattening, etc
Dave Longley: The hashing mechanism is important because JSON-LD allows you to markup data in a variety of different ways, normalization allows you to take documents that may be the same and do a comparison to see if they are actually the same. [scribe assist by Manu Sporny]
Manu Sporny: it's a comparison of the data in the document, not the layout of the document
Manu Sporny: it checks to see if the information in the documents is the same, which is a pretty big advance
Manu Sporny: you could use JSON-LD with the JOSE stack, but because there's a digital signature mechanism in there, the end result is that whenever you pass information from one website to another, you don't have to pass the serialized form of that information
Manu Sporny: if you look at a JWT they base64 encode the data being signed, and the reason they may have done that is to avoid the hard normalization problem
Manu Sporny: because its' a very complex problem, and we thought it was worth addressing that problem, because it means you can do digital signatures on the information itself and the syntax that you use to express that data doesn't matter
Manu Sporny: using JSON-LD you can generate a digital signature for that data and then express the information in another way elsewhere
Manu Sporny: use RDFa for instance, on a web page to express data that is expressed as JSON-LD in another way (or maybe microdata, etc)
Manu Sporny: if we're wrong about a particular format/syntax we can change it later and the digital signatures will still wrok
Manu Sporny: with JWT the requirement to transmit the data is always there
Manu Sporny: Does that make sense, Kumar?
Kumar McMillan: yes, i could follow that, i've been following your posts and it makes sense to me
Dave Longley: It also helps because different clients may request different types of data from that URL. If a client only reads JSON-LD, or RDFa, different clients can get the data in different ways. [scribe assist by Manu Sporny]
Dave Longley: It's also worth pointing out that we have multiple implementations for this now. It works in the PaySwarm developers site, meritora, PHP, JavaScript, and Python implementations of the JSON-LD digital signature stuff. [scribe assist by Manu Sporny]
Dave Longley: We also have an older C++ implementation of this stuff that we could update if needed. [scribe assist by Manu Sporny]

Topic: JSON Web Key (JWK)

Manu Sporny: so the JWA stuff is a bad of cryptographic primitives that the JOSE stuff needs that the Secure Messaging approach doesn't need
Manu Sporny: (different approaches)
Manu Sporny: so JWK is a way of expressing keys in JSON
Manu Sporny: JOSE JWK key format: {
Manu Sporny: "keys": [{
Manu Sporny: "kty":"RSA",
Manu Sporny: "n": "0vx7agoe ... DKgw",
Manu Sporny: "e":"AQAB",
Manu Sporny: "alg":"RS256",
Manu Sporny: "kid":"2011-04-29"
Manu Sporny: }]
Manu Sporny: }
Manu Sporny: the information is broken down into its components
Manu Sporny: this is an RSA key
Manu Sporny: Secure Messaging key format: {
Manu Sporny: "@context": "https://w3id.org/security/v1",
Manu Sporny: "@type": "Key",
Manu Sporny: "owner": "https://example.com/i/bob",
Manu Sporny: "publicKeyPem": "-----BEGIN PRIVATE KEY-----\nMIIBG0BA...OClDQAB\n-----END PRIVATE KEY-----\n"
Manu Sporny: }
Manu Sporny: Secure Messaging deviates from JWK in a few ways, first there's a URL that identifies the key so you can always find out which key people are talking about (you can use UUID if you want to etc, any IRI, but URL is best practice)
Manu Sporny: the other thing specified is an identity associated with the key, also a URL right now, maybe email addresses could be used in the future
Manu Sporny: the key idea is that you can find out who the owner of the key is
Manu Sporny: you should be able to go to a URL that also asserts that bob owns the key
Manu Sporny: once there is a two-way association is set up you can be sure the key is owned by the identity
Kumar McMillan: to clarify, the persona idea is something is at a domain, so it could be a phone number at a domain, etc.
Kumar McMillan: To clarify, the Persona approach can be something@domain.com - so 555-555-5555@tmobile.com [scribe assist by Manu Sporny]
Kumar McMillan: it's really about the domain in persona
Manu Sporny: we talked with some of the persona folks and they asked if we were interested in using persona for identity, for example could you just do login with persona on websites, and we could so long as we could attach other information to the identity assertion
Manu Sporny: we would like to be able to include things like home address/shipping address, etc.
Manu Sporny: the payswarm identity spec lets you associated arbitrary data and we need some info for the payment process in payswarm
Manu Sporny: and we don't know if persona can support that
Manu Sporny: right now we're using URLs instead of emails because it's much easier to just dereference to get more info (and assert key ownership)
Kumar McMillan: the persona idea will be that the domain has .well-known with extra information, but that's separate from storing preferences, so the idea behind storing preferences for payment/identity is something that persona is addressing right now because they are pretty close to landing what is code named PICL
Kumar McMillan: which is a way to sync profile data, which will start with firefox profile data, which is something they are actively working on now, so you can associate arbitrary data with an identity, i know it's pretty experimental right now, still in the works for a wihle
Manu Sporny: so that's something that we're trying to coordinate with the identity team at mozilla but it's been kind of difficult, it didn't seem like a priority for them 3-6 months ago, we'll try and ping them again
Kumar McMillan: 3-6 months ago, yeah, that was on the horizon, syncing profile data is a priority now, i've seen a full working prototype of it, i've seen people using firefox syncing things with persona servers and it's in implemtnation for production stage now
Manu Sporny: so when you log in i guess what you do is say you're ok with sharing your home address/whatever with the site in question?
Kumar McMillan: i don't know if they are working on the exchange between identity providers yet, i think they may be working at protocol level right now, there's no use case for syncing profile data for sharing with an identity provider i don't think yet
Manu Sporny: the other approach that we're thinking of here is ... the web payments work will require getting shipping addresses to merchants at some point ... the other idea we were talking about was having the vendor say, hey i need a shipping address, and when someone goes to buy the window for the purchase would say the vendor needs the shipping address and the buyer has to consent or change their shipping address or cancel the purchase
Manu Sporny: at that point the shipping address might be embedded into the contract to get it to the vendor
Manu Sporny: that might be better because there's not a requirement for persona to deal with that information
Kumar McMillan: i don't know if persona is going to get involved in being a gatekeeper of that information, btu one thing that's getting a lot of interest, there's pressure on mozilla to implement request auto-complete
Kumar McMillan: i don't know if it will happen in its current form but it sounds like this might be a perfect tool for that to happen
Kumar McMillan: where someone asks for a shipping address and you already have it in your browser on your client, that is a little different because you're putting it into a contract and you can't take it from a browser and put it into a contract because there's no URL
Manu Sporny: ok that's one of those issues floating out there we'll have to deal with at some point
Manu Sporny: going back to the key format, there's publicKeyPem
Manu Sporny: the JWK approach breaks out the parameters for the key, we took a different approach
Manu Sporny: it's difficult for developers to understand what those parameters are and they'd rather cut and paste data
Manu Sporny: and pem is something every crypto library uses
Manu Sporny: instead of having to understand all the parameters, point on a curve, etc. which is what JWA does, instead it's in PEM format and we just expose stuff as PEM data on the web and you don't have to worry about you've copied the right information, left something out, etc.
Manu Sporny: that approach was seen as controversial in the WebID community because they thought that the most raw cryptographic form should be used, but we don't think that's developer friendly, we think copying info around as a blog with a clear beginning and end is better
Manu Sporny: ultimately the Secure Messing key format is simpler to understand and publish and you can put it on the web and another app/client can come along and do key discovery on it, key retrieval, verification, etc. all via that simple key format, it's just a doc on the web and you can do everything you need to using just a doc on the web following links in the doc
Manu Sporny: any questions?
Manu Sporny: next is JWT

Topic: JSON Web Tokens (JWT) vs. Secure Messaging

Manu Sporny: JWT is basically what most of mozilla uses right now to do digital signatures
Manu Sporny: it's a container format that you put claims into and then you digitally sign those tokens using the JWS spec
Manu Sporny: let me get an example
Manu Sporny: JWTs look like this: {
Manu Sporny: "iss": "joe",
Manu Sporny: "exp": 1300819380,
Manu Sporny: "http://example.com/is_root": true
Manu Sporny: }
Manu Sporny: and Secure Messaging messages look like this: {
Manu Sporny: "@context": "http://json-ld.org/contexts/person",
Manu Sporny: "@type": "Person",
Manu Sporny: "name": "Manu Sporny",
Manu Sporny: "gender": "male",
Manu Sporny: "homepage": "http://manu.sporny.org/"
Manu Sporny: }
Manu Sporny: the big difference between JWT and Secure Messaging is that JWT is a container format, and Secure Messaging doesn't need a container format, you just have information, digitally sign it, and include the signature in the data you're signing
Manu Sporny: the core argument against JWT is that it's unnecessary with Secure Messaging
Manu Sporny: at this point, the Secure Messaging approach eliminates JWA (it doesn't need to be a 70 page spec at least), it doesn't need something like JWT, it just uses the JSON data using JSON-LD and includes the signature in the data
Manu Sporny: so the last two bits are JWE and JWS

Topic: JSON Web Encryption (JWE) vs. Secure Messaging

Manu Sporny: JWE Encrypted JSON looks like this: {
Manu Sporny: "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
Manu Sporny: "unprotected": {"jku": "https://server.example.com/keys.jwks"},
Manu Sporny: "recipients": [{
Manu Sporny: "header": {
Manu Sporny: "alg":"RSA1_5"
Manu Sporny: "kid":"2011-04-29",
Manu Sporny: "enc":"A128CBC-HS256",
Manu Sporny: },
Manu Sporny: "encrypted_key": "UGhIOgu ... MR4gp_A"
Manu Sporny: }]
Manu Sporny: }],
Manu Sporny: "iv": "AxY8DCtDaGlsbGljb3RoZQ",
Manu Sporny: "ciphertext": "KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
Manu Sporny: "tag": "Mz-VPPyU4RlcuYv1IwIvzw"
Manu Sporny: }
Manu Sporny: for comparison this is what a Secure Messaging encrypted message looks like: {
Manu Sporny: "@context": "https://w3id.org/security/v1",
Manu Sporny: "@type": "EncryptedMessage2012",
Manu Sporny: "data": "VTJGc2RH ... Fb009Cg==",
Manu Sporny: "encryptionKey": "uATte ... HExjXQE=",
Manu Sporny: "iv": "vcDU1eWTy8vVGhNOszREhSblFVqVnGpBUm0zMTRmcWtMrRX==",
Manu Sporny: "publicKey": "https://example.com/people/john/keys/23"
Manu Sporny: }
Manu Sporny: the parameters aren't that different, you've got encryption key, iv, cipher text, the key difference here is that the Secure Messaging is much simpler, in that you just have base64-encoded data
Manu Sporny: with JWE you have headers, the keys expressed within the data, you've got unprotected keys outside of the message, etc.
Manu Sporny: it seems really hard(er) to work with
Manu Sporny: whereas with the Secure Messaging data you've just got data that is encrypted and one decryption mechanism that you apply to the encrypted data to get at it
Manu Sporny: at a high-level the difference is in how the JWE expresses the encryption parameters, because they dont' go with the "best practices" approach, there's more complexity, so you need headers that are like email headers and they can get complex, and the Secure Messaging spec says there's just one best practice mechanism for these things and then you don't have protected/unprotected info either
Manu Sporny: JWE lets you use lots of different types of encryption, but it's not really clear what that really buys you for the added complexity
Kumar McMillan: just to clarify, if someone did want to make their own algorithm or a new one, they'd just make a custom context and host that at a URL
Manu Sporny: Yeah, this is basically the only change you'd have to make: "@type": "http://mycrypto.com/algorithms/MySpecialAlgorithm"
Manu Sporny: they wouldn't even have to create a custom context at a URL if they didn't want to, they could just embed it
Dave Longley: If someone adds another one, and it becomes popular, then we just integrate it. [scribe assist by Manu Sporny]
Kumar McMillan: right, i definitely think that highlights a major advantage, i guess that's JSON-LD that provides that advantage
Kumar McMillan: With JWE, they have to incorporate a new algorithm in the spec for anyone to be able to use it. [scribe assist by Manu Sporny]
Kumar McMillan: with JWE they would *have* to incorporate a new algorithm into the spec
David I. Lehn: Those types can have their own description as well. [scribe assist by Manu Sporny]
Manu Sporny: if you got to the security spec if you look up the type identifiers for GraphSignature2012 or EncryptedMessage2013/2012 (whatever it is) it breaks down the algorithms in use for you
Manu Sporny: if you use a JSON-LD agent to go to a URL you can extract the exact parameters you need
Manu Sporny: from the document
Manu Sporny: most people will just hard code it, which is fine
Brent Shambaugh: bye

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