- From: Harry Halpin <hhalpin@w3.org>
- Date: Wed, 19 Nov 2014 20:47:05 +0100
- To: Dave Longley <dlongley@digitalbazaar.com>
- CC: public-credentials@w3.org
On 11/19/2014 08:26 PM, Dave Longley wrote: > On 11/19/2014 02:16 PM, Harry Halpin wrote: >> Just read the charter. It's out of scope and will remain so. > > I did. The Linked Data Platform (where JSON-LD is a requirement) is > mentioned as a possible input to the "Federation Protocol" > Recommendation-Track deliverable. It would allow the federation of "data > (such as profile information) between heterogeneous Web-based social > systems." It seems like "profile information" could be signed Linked > Data to me, such as the types of Credentials that are being discussed in > the Credentials Community Group. If this isn't a reasonable conclusion, > then I suggest the charter language be tweaked. No, the language of the charter clearly states: "should include a serialization compatible with Javascript (JSON)" [1] JSON-LD is "possibly" and some WG members object to making it a hard requirement. I have no idea what the Credential CG is proposing in detail, but if they use JSON they should probably use JOSE, as I doubt any WG-level deliverables would go be accepted otherwise. It's good to separate the graph normalization from any singature work, as that could then be used before embedding in JOSE while not having RDF fans go off into a separate parallel universe from the rest of the Web. [1] http://www.w3.org/2013/socialweb/social-wg-charter.html > >> >> On 11/19/2014 08:06 PM, Dave Longley wrote: >>> On 11/19/2014 01:49 PM, Harry Halpin wrote: >>>> Elf - please stop cross-posting to lists wanting out of scope >>>> deliverables. >>>> >>>> On 11/19/2014 07:36 PM, Dave Longley wrote: >>>>> On 11/19/2014 01:09 PM, Harry Halpin wrote: >>>>>> To be clear, I think the Social WG will use JOSE for all existing and >>>>>> future Web standards in this space where digital signatures and JSON >>>>>> delivery of encryption is required for the aforementioned reasons >>>>>> (none >>>>>> of which seem seriously argued with below - note that key >>>>>> discovery is >>>>>> orthogonal to formats), as new signature formats are out of scope for >>>>>> the Social WG. >>>>>> >>>>>> They are in scope for the JOSE WG. If you wish to have a discussion >>>>>> with >>>>>> JOSE, you are more than welcome to take that up that up with the >>>>>> JOSE WG >>>>>> at the IETF, although be clear that SM is not a competing >>>>>> specification >>>>>> or standard by the W3C but an pronto-specification of a Community >>>>>> Group. If the IETF wishes to adopt some part of SM, they could. >>>>>> >>>>>> The W3C co-ordinates with IETF over standards and so it makes no >>>>>> sense >>>>>> for the W3C to produce a competing standards for signing and >>>>>> encrypting >>>>>> JSON. All Payments-based future work simply adopt JOSE as needed, >>>>>> and if >>>>>> the use-cases of SM are actually realistic, they can be taken up >>>>>> by the >>>>>> JOSE WG in future versions. >>>>> It should be noted that the SM/RDF-normalization work is not about >>>>> signing JSON; it's about signing any data that uses the RDF data >>>>> model. >>>>> We wouldn't be standardizing a digital signature on JSON data, as no >>>>> JSON is signed in this approach. Rather, we would standardize a way to >>>>> generate and represent a signature on an RDF dataset. That signature >>>>> could be transported in JSON (as JSON-LD) as just one possible syntax. >>>>> It would be the preferred way to digitally sign Linked Data. >>>> Again, the Social Web WG is not the RDF Working Group, but is mandated >>>> to use JSON - not any other format, and will only use JSON-LD as it >>>> makes some level of sense. Having a separate signature does not make >>>> any >>>> sense as we are chartered for JSON and would like to be compatible with >>>> the rest of the Web that uses JOSE and JSON. >>> We're not *only* talking about the Social Web WG, though we have >>> mentioned that the work that's going on in other groups that are >>> interested in Linked Data may be of interest to the Social Web WG. You >>> have mentioned Web Payments in your responses as well, where Linked Data >>> has been part of the discussion. >>> >>> Obviously, if the Social Web WG has decided that it must primarily be >>> compatible with the corner of the Web that exclusively uses JOSE and >>> JSON then I can understand a strong desire to reuse JOSE. I still do >>> think it's worth mentioning work that may result in support of a broader >>> set of use cases in the event that there is interest. If the Social >>> Web's scope is to be as narrow as you suggest, then I do see how JOSE >>> can make sense. >>> >>>> For RDF-centric questions about how to sign any possible graph in any >>>> possible syntax, please ask to recharter the RDF WG via asking an >>>> appropriate staff contact or ask an appropriate WG. It is unclear if >>>> IETF JOSE would be bothered to care, but you can always ask them for >>>> consideration. >>>> >>>> For the Social Web WG, as regards JSON, we will use JOSE as SM is >>>> out of >>>> scope as its not part of our deliverables. If another WG >>>> standardizes SM >>>> (which I would be doubtful of), then I'm happy to reconsider. >>>> >>>> In my opinion, it would probably make more sense to graph normalization >>>> to canonical graphs in a separate spec rather than bundle that with >>>> signatures. >>> RDF normalization is already in a separate spec, which is why I've been >>> referring to SM/RDF-normalization and not just SM. >>> >>>> thanks, >>>> harry >>>> >>>>>> cheers, >>>>>> harry >>>>>> >>>>>> >>>>>> On 11/19/2014 05:31 PM, Dave Longley wrote: >>>>>>> On 11/18/2014 11:20 AM, ☮ elf Pavlik ☮ wrote: >>>>>>>> Feedback from Harry Halpin, who acts as W3C staff contact in >>>>>>>> Social WG >>>>>>>> and Web Cryptography WG. >>>>>>>> >>>>>>>> -------- 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. >>>>>>> It's true that these are pros for an existing technology. As Manu >>>>>>> mentioned, there are also drawbacks for JOSE -- as is the case >>>>>>> for any >>>>>>> technology. I think there's a debate worth having here. Note that >>>>>>> the >>>>>>> pros listed here can only be the result of a technology that has >>>>>>> been >>>>>>> around longer than the alternatives under consideration. A new >>>>>>> technology that addresses the drawbacks of JOSE, while bringing >>>>>>> along >>>>>>> less undesirable drawbacks of its own, could similarly go through >>>>>>> security review, make use of W3C WebCrypto, and potentially gain >>>>>>> wide >>>>>>> use. These aren't advantages that speak to the technology itself. >>>>>>> >>>>>>>> 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. >>>>>>> Just to be clear: The JSON-LD solution can also work for generic >>>>>>> JSON in >>>>>>> the same way that the JOSE solution does. JOSE effectively strips >>>>>>> away >>>>>>> the JSON formatting in the signed payload by obscuring everything >>>>>>> as a >>>>>>> base64 blob. You could just as easily take a base64 blob and put it >>>>>>> in a >>>>>>> JSON-LD container as you could put it in a JOSE JSON container. >>>>>>> So the >>>>>>> JSON-LD approach already supports what JOSE does, as you can mark >>>>>>> up a >>>>>>> JOSE JSON message as JSON-LD. Using an RDF normalization >>>>>>> algorithm to >>>>>>> produce a canonical serialization to be digitally signed adds >>>>>>> value. For >>>>>>> example, it works with *more* than just JSON; it allows you >>>>>>> digitally >>>>>>> sign data that is transported using any RDF syntax. I'd expect that >>>>>>> kind >>>>>>> of technology to be very valuable to the Social Web -- and the >>>>>>> Web in >>>>>>> general. >>>>>>> >>>>>>> By the way, let's be careful not to use language that personalizes >>>>>>> this >>>>>>> by making it seem like it's "Manu's idea" -- this is a much older >>>>>>> and >>>>>>> more widespread idea. That may not be your intent. >>>>>>> >>>>>>>> There's no reason why that >>>>>>>> step can't be done before before base 64 encoding and signing. >>>>>>> This is true. But you don't have to be locked into a JOSE JSON >>>>>>> syntax, >>>>>>> rather you can use any RDF syntax, if you take the RDF normalization >>>>>>> approach to digital 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. >>>>>>> This isn't related to digital signatures that rely on RDF >>>>>>> normalization, >>>>>>> per se, rather it relates to a philosophical difference between the >>>>>>> Secure Messaging approach and the JOSE and IETF approach. The JOSE >>>>>>> approach is to specify and implementation all possible (with >>>>>>> appropriate >>>>>>> security considerations) crypto algorithms. Extensions are >>>>>>> centralized >>>>>>> via the IETF process. The Secure Messaging approach is to recommend >>>>>>> only >>>>>>> one very good algorithm and require that just that algorithm be >>>>>>> implemented. This can change as needed as the crypto space >>>>>>> evolves. It >>>>>>> then allows for algorithmic agility by using the decentralized >>>>>>> extensibility inherent in Linked Data. These are simply different >>>>>>> ways >>>>>>> to approach the same problem; it's subjective which is preferred >>>>>>> and I >>>>>>> would expect people to differ. >>>>>>> >>>>>>>> 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. >>>>>>> The proposed alternative key discovery mechanism is much more "Web >>>>>>> first". A key resides at a URL. You follow your nose to that URL and >>>>>>> you'll find Linked Data there that describes the key, including >>>>>>> information such as who supposedly owns the key. The URL for that >>>>>>> owner >>>>>>> is where you can get more Linked Data to confirm that the same >>>>>>> key has >>>>>>> been listed. This information can be used to assert ownership >>>>>>> over the >>>>>>> key. This same mechanism has been used with WebID. I'd expect this >>>>>>> approach to be attractive to the Social Web (and again, the Web in >>>>>>> general). >>>>>>> >>>>>>>> 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. >>>>>>> That's because it's an alternative; a new technology that hasn't yet >>>>>>> been standardized. This sounds like begging the question, a round >>>>>>> about >>>>>>> way of restating definitions that ignores the point of contention. I >>>>>>> think the definition of a new alternative *requires* that there be >>>>>>> less >>>>>>> adoption. The point of contention is whether or not the new >>>>>>> alternative >>>>>>> (Secure Messaging and/or RDF normalization-based digital signatures) >>>>>>> should be used over the existing JOSE stack. Also, just for >>>>>>> clarity, the >>>>>>> technology is new, but has some basis in ideas that been around >>>>>>> for a >>>>>>> while. >>>>>>> >>>>>>> As an aside: perhaps you are just using terms like "Manu's >>>>>>> alternative" >>>>>>> to describe this technology in a quick way, but when you couple that >>>>>>> with "his Community Groups" in the same sentence it makes it sound >>>>>>> like >>>>>>> you're dismissing the technology as a personal idea of his. Manu is >>>>>>> certainly a vocal, active member, and leader in the Community Groups >>>>>>> you're referencing. But your choice of words seems disparaging to >>>>>>> the >>>>>>> other members in those groups and to others who have worked on these >>>>>>> ideas or parts of them for much longer than those groups have >>>>>>> existed. >>>>>>> I'm going to give you the benefit of the doubt that this is >>>>>>> unintentional; I'd just suggest using different language in the >>>>>>> future. >>>>>>> >>>>>>>> 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. >>>>>>> I do agree that we shouldn't fragment standards unnecessarily. I >>>>>>> also >>>>>>> think that the Secure Messaging/RDF-normalization approach brings a >>>>>>> lot >>>>>>> to the table. The main benefit of the JOSE approach appears to be >>>>>>> age >>>>>>> (and thus, adoption, et. al) -- as you mentioned. That's useful, but >>>>>>> something an alternative can gain with time. I think a debate in >>>>>>> this >>>>>>> space is appropriate. >>>>>>> >>>>>>> -Dave >>>>>>> >>>>>>> >>>>>>>> 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 Wednesday, 19 November 2014 19:47:18 UTC