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

On 21 November 2014 15:59, Harry Halpin <hhalpin@w3.org> wrote:

>
>
> On 11/21/2014 03:55 PM, Melvin Carvalho wrote:
> > 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.
>
> Yes, the official W3C position is that we have to depend on normative
> specs in normative specs. And that fragmenting the Web is a bad idea
> (i.e. RDFa/microdata/microformats, XHTML2, etc.)
>

But JSON LD is already a REC.  Signing linked data using linked data is a
curious perspective of "fragmentation", imho


>
> For non-JSON signatures, feel free to create an alternative spec but it
> would require real standardization, security review, and proof of heavy
> deployment to count as "normative". The CGs - including Credentials and
> Web Payments -  are *not* standards-level WGs BTW.
>

The last time I presented a payments use case to you, ie that the bitcoin
ECC curve should be included in the web crypto named curve registry, you
said the same thing.  Bitcoin has significant deployment, the curve is well
deployed, has 1000s of developers, and cast iron security, and the crypto
WG that you chaired didnt add it.  It was the web payments group that had
negative blogs posts directed at it, for not including crypto, even though
manu has been very inclusive of any crypto currency folks that wanted to
join.

So there's definitely elements of picking and choosing going on.  I feel
our comments are over stretching the w3c position.  We need signing in RDF,
and that naturally will come down to all serializations that support graphs
such as JSON LD, TriG etc.  The logical way to do this is in band, but it's
perfectly fine to use JOSE if that tool suits the purpose, let's try not to
dictate too much here, but rather, look at the pros and cons as Manu has.


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