- From: Harry Halpin <hhalpin@w3.org>
- Date: Wed, 19 Nov 2014 20:16:35 +0100
- To: Dave Longley <dlongley@digitalbazaar.com>
- CC: public-credentials@w3.org
Just read the charter. It's out of scope and will remain so. 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:16:43 UTC