- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 22 Aug 2013 22:43:52 -0400
- To: Web Payments <public-webpayments@w3.org>
Thanks to Dave Longley for scribing yesterday! The minutes for this
week's Web Payments telecon are now available here:
https://payswarm.com/minutes/2013-08-21/
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 2013-08-21
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2013Aug/0040.html
Topics:
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
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Manu Sporny, Kumar McMillan, Andrei Oprea,
David I. Lehn, Brent Shambaugh
Audio:
http://payswarm.com/minutes/2013-08-22/audio.ogg
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?
Manu Sporny: http://manu.sporny.org/2013/sm-vs-jose/
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:
{
"keys": [{
"kty":"RSA",
"n": "0vx7agoe ... DKgw",
"e":"AQAB",
"alg":"RS256",
"kid":"2011-04-29"
}]
}
Manu Sporny: the information is broken down into its components
Manu Sporny: this is an RSA key
Manu Sporny: Secure Messaging key format:
{
"@context": "https://w3id.org/security/v1",
"@id": "https://example.com/i/bob/keys/1",
"@type": "Key",
"owner": "https://example.com/i/bob",
"publicKeyPem": "-----BEGIN PRIVATE
KEY-----\nMIIBG0BA...OClDQAB\n-----END PRIVATE KEY-----\n"
}
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:
{
"iss": "joe",
"exp": 1300819380,
"http://example.com/is_root": true
}
Manu Sporny: and Secure Messaging messages look like this:
{
"@context": "http://json-ld.org/contexts/person",
"@type": "Person",
"name": "Manu Sporny",
"gender": "male",
"homepage": "http://manu.sporny.org/"
}
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:
{
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected": {"jku": "https://server.example.com/keys.jwks"},
"recipients": [{
"header": {
"alg":"RSA1_5"
"kid":"2011-04-29",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"
},
"encrypted_key": "UGhIOgu ... MR4gp_A"
}]
}],
"iv": "AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag": "Mz-VPPyU4RlcuYv1IwIvzw"
}
Manu Sporny: for comparison this is what a Secure Messaging
encrypted message looks like:
{
"@context": "https://w3id.org/security/v1",
"@type": "EncryptedMessage2012",
"data": "VTJGc2RH ... Fb009Cg==",
"encryptionKey": "uATte ... HExjXQE=",
"iv": "vcDU1eWTy8vVGhNOszREhSblFVqVnGpBUm0zMTRmcWtMrRX==",
"publicKey": "https://example.com/people/john/keys/23"
}
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
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/
Received on Friday, 23 August 2013 02:44:31 UTC