Re: [Moderator Action] Re: Fwd: Re: Fwd: Digital Signatures for Credentials

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.

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.

  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 18:49:21 UTC