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

Melvin +100 thanks for being a voice of reason.
On Nov 21, 2014 12:37 PM, "Melvin Carvalho" <melvincarvalho@gmail.com>
wrote:

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