Re: Fwd: Re: Fwd: Digital Signatures for Credentials

On 19 November 2014 19:09, Harry Halpin <hhalpin@w3.org> 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.
>

Harry, perhaps I am misreading your statement, it's absurd to advocate that
*all* payments based future work adopt JOSE, imho.  Not least for the fact
that not all payments work on the web will even be JSON.  I am already
reusing the normalization and signature work that has been largely
standardized by the web payments and credential group.

Hard to imagine that this can be an official W3C position.


>
>    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
> >>>
> >>
> >>
> >>
> >
> >
>
>