Just read the charter. It's out of scope and will remain so.
On 11/19/2014 08:06 PM, Dave Longley wrote:
> On 11/19/2014 01:49 PM, Harry Halpin wrote:
>> 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.
>
> We're not *only* talking about the Social Web WG, though we have
> mentioned that the work that's going on in other groups that are
> interested in Linked Data may be of interest to the Social Web WG. You
> have mentioned Web Payments in your responses as well, where Linked Data
> has been part of the discussion.
>
> Obviously, if the Social Web WG has decided that it must primarily be
> compatible with the corner of the Web that exclusively uses JOSE and
> JSON then I can understand a strong desire to reuse JOSE. I still do
> think it's worth mentioning work that may result in support of a broader
> set of use cases in the event that there is interest. If the Social
> Web's scope is to be as narrow as you suggest, then I do see how JOSE
> can make sense.
>
>> 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.
>
> RDF normalization is already in a separate spec, which is why I've been
> referring to SM/RDF-normalization and not just SM.
>
>>
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>
>