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

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.

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


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Wednesday, 19 November 2014 18:36:27 UTC