- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 18 Nov 2014 19:31:18 +0100
- To: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>, public-credentials@w3.org
On 2014-11-18 17:20, ☮ elf Pavlik ☮ wrote: > Feedback from Harry Halpin, who acts as W3C staff contact in Social WG > and Web Cryptography WG. It doesn't matter what the IETF or W3C thinks, the notion that you must support third-rate JSON parsers that doesn't even preserve property order is exaggerated. Cleartext signatures based on JSON is an already solved problem: https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserAuthorizesTransaction Works without modifications using the built-in JSON parser in all major browsers. However, I don't really understand the point with graph normalization unless that is an intrinsic part of JSON-LD. Anders > > -------- Forwarded Message -------- > Subject: Re: Fwd: Digital Signatures for Credentials > Resent-Date: Tue, 18 Nov 2014 16:13:12 +0000 > Resent-From: public-socialweb@w3.org > Date: Tue, 18 Nov 2014 17:13:02 +0100 > From: Harry Halpin <hhalpin@w3.org> > To: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>, > public-socialweb@w3.org <public-socialweb@w3.org> > > I believe if we have to do signed data in the Social Web, we'll use > JOSE, as that is supported widely, has gone through widespread security > review in the IETF where it was standardized, and is supported in > browsers via W3C WebCrypto. > > I believe the largest difference seems to be that JOSE is for generic > JSON, while Manu's idea for signatures specializes for JSON-LD and thus > includes a graph normalization step for RDF. There's no reason why that > step can't be done before before base 64 encoding and signing. JOSE also > allows algorithm agility and a much more complete stack of > key/signatures algorithms and functionality. I'm pretty sure any future > standards-track work out of Web Payments will also be based on JOSE, as > the W3C has worked closely with IETF over JOSE during its standardization. > > In JOSE, public keys are discovered how keys are normally discovered in > ASN.1 format (i.e keyservers, etc.), and the opaque blob format (base 64 > encoded) is because signatures works over raw bits, which can be easily > screwed up in cleartext. Taking strings in and out of base 64 encoding > is pretty trivial. Many more web developers, including all major > browser vendors including Mozilla, use and support JOSE. I don't know of > anyone uses Manu's alternative to my knowledge outside of a few people > in his Community Groups. > > In general, I think it's better not to roll one another stacks in the > crypto space due to security concerns (for example, sending a signature > separate from the data in cleartext allows the signature to be trivially > swiped and replaced by another one, i.e. see signature wrapping attacks > on XML-DSIG), and it's generally not a good idea to fragment standards > unnecessarily. > > cheers, > harry > > > On 11/18/2014 04:53 PM, ☮ elf Pavlik ☮ wrote: >> I remember some conversation during TPAC about systems behind firewall >> not fit to make requests back to some other server as required in >> webmention.org . I think that JSON-LD Secure Messaging could offer some >> solutions here. >> >> Mozilla Open Badges already have hosted version (similar to how pattern >> used for WebMention works) as well as signed version, both explained in >> current (pre JSON-LD) spec: >> https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md#badge-verification >> >> >> -------- Forwarded Message -------- >> Subject: Digital Signatures for Credentials >> Resent-Date: Mon, 17 Nov 2014 02:32:41 +0000 >> Resent-From: public-credentials@w3.org >> Date: Sun, 16 Nov 2014 21:32:16 -0500 >> From: Manu Sporny <msporny@digitalbazaar.com> >> To: Credentials Community Group <public-credentials@w3.org> >> >> During the call last week, we touched on the last major item (digital >> signatures) that needs to be aligned between the Badge Alliance >> technology stack and the Credentials technology stack. Like all >> technology, there are upsides and downsides to each approach. I thought >> I'd try and summarize them in this email. >> >> The Credentials technology stack[1] focuses on extensibility via Linked >> Data / JSON-LD and thus uses a digital signature mechanism that was >> built for graph-based data. >> >> The Badge Alliance technology stack had focused on pure JSON data and >> re-using the IETF's JOSE digital signature stack. I've written about >> Digital Bazaar's concerns with JOSE before[2]. >> >> In general, both technologies allow a developer to: >> * Digitally sign data >> * Verify digitally signed data >> * Express public/private keypairs >> * Encrypt and decrypt data in message envelopes >> >> In this respect, neither technology is that different from what XML >> Digital Signatures enables one to do. >> >> Both SM and JOSE use JSON as the basic container format due to JSON's >> popularity with developers. When comparing the SM vs. JOSE technology >> stacks, here are some of the key pros/cons: >> >> JSON-LD Secure Messaging Pros: >> * Clear-text signatures (easier to see/debug what's going on) >> * Works with any RDF syntax (N-Quads, TURTLE, etc.) >> * Ensures discoverability of public keys via the Web >> * Simpler interface for Web developers >> * Extensible message format due to JSON-LD >> * Designed to integrate cleanly with HTTP Signatures >> * Identified as a need for both the Social Web WG and >> Web Annotations WG due to dependence on JSON-LD >> >> JSON-LD Secure Messaging Cons: >> * Not an official standard yet >> * Graph Normalization algorithm is hidden from developers, but >> very complex >> >> JOSE Pros: >> * First mover advantage >> * Already an IETF standard with thorough security review >> * More software libraries exist for JOSE >> >> JOSE Cons: >> * Signed data is an opaque blob, which is very difficult to try and >> debug >> * Fairly difficult to use for Web developers due to exposing too much >> complexity >> * Format is not extensible, requires coordination through IETF >> * No standardized public key discoverability mechanism >> >> The biggest downside with the SM approach is that it's not a W3C >> standard yet and that will take some time (1-2 years). The technology is >> done and there are multiple interoperable implementations out there, so >> we're not concerned about it not getting through the standardization >> process once it enters the process. With the recent hallway discussion >> at W3C TPAC, we feel that we should be able to get the minimum number of >> W3C member votes necessary to take the specs REC-track. >> >> So, with that introduction - are there any thoughts on SM vs. JOSE? Does >> anyone feel that strongly one way or the other? Any pros/cons that are >> not in the list above that should be? >> >> -- manu >> >> [1] http://opencreds.org/specs/source/roadmap/#technology-stack >> [2] http://lists.w3.org/Archives/Public/public-webpayments/2013Aug/0004.html >> > > > >
Received on Tuesday, 18 November 2014 18:31:52 UTC