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

On 22 November 2014 at 20:31, Harry Halpin <hhalpin@w3.org> wrote:

> On 11/21/2014 06:36 PM, Melvin Carvalho 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
>
> Again, the topic was JSON-based signatures, not JSON-LD's normative
> status. JSON-LD adds a number of sensible capabilities for RDF on top of
> JSON. I see no similar advantages to SM.
>
> >
> >
> >>
> >> 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.
>
> The WebCrpypto API does not add curves that won't *actually* be
> implemented (or are already implemented and so can be easily exposed) by
> actual browser vendors. Otherwise, the WG would be producing a standard
> as "wishful thinking" rather than being an inter-operable standard - and
> in the end would in the end confuse and be a disservice to developers.
> We have spent the last 6 months developing an extension mechanism in the
> latest version of the WebCrypto spec. Please use it.
>
> Just sending a single email is not enough. If you wish any
> Bitcoin-specific crypto (i.e. secp256k1 elliptic curve crypto) to be
> included, please simply author an extension specification (or find
> someone that will) and the extension will be considered.  If there is
> demand, it may be implemented. For example, an extension spec has
> already been done for Curve 25519 and we expect to extend based on CFRG
> recommendations around ECC.
>
> >
> > 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.
>
> Yes, and SM was not accepted by the IETF. I suggsted CG could always try
> again later with an improved spec or by modularizing the SM concepts and
> clearly separating out various parts and use-cases. However, calling
> something "Secure Messaging" is probably a bad idea (one should probably
> say "RDF signatures" to be more accurate), particularly when a
> well-known cryptographer such as Manger found a number of beginner
> crypto errors in a draft. Further, pretending it is a "standard" or
> endorsed by the W3C is problematic insofar as it caused confusion as the
> IETF thought it was a W3C position. My suggested next steps are clear
> (i.e. get wider review in JOSE WG for your use-caes)  and the chairs of
> the Social Web WG have also concurred this is out of scope for Social
> Web. In general, crypto is hard so wide review is necessary.  The W3C
> process (and IETF process)  exist to create widespread review and
> implementation.
>
> The general strategy of taking a note made by a few people, branding it
> a "W3C specification" due to a Community Group process, and then
> pretending something is a normative standard and pushing it on other WGs
> or outsiders who may not know any better is something to be actively
> discouraged for *any specification*. Instead, get widespread review and
> real implementation/vendors on board and go with W3C or IETF process.
>

Thanks for the response.

To quote danbri, "It's best to avoid words like 'pretend' when talking
about other people's actions and intentions. Good typically doesn't come of
it..."

IMHO, this thread is aiming to outline the pros and  cons of each approach
and collate them with respect to certain use cases.  If we could frame
things in those terms, I think the conversation could be productive.

Security review is invaluable, and hopefully an evolving process, however I
think it would be fair to say relatively few people at the IETF well versed
in linked data, which is has been the central building block of the web
payments work, and has been for many years.

My personal view, is that I would like to sign linked data with linked
data, it makes a lot of sense to me, and for web payments and I welcome
this innovation.  And I am in the process of implementing some real world
use cases.

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