Subject: [jose] Review Comments: Web Payments, Secure Messaging, and JOSE

From: Manu Sporny <[email-masked]>
Date: Wed, 11 Dec 2013 16:44:28 -0500

Hi all,

These are review comments on the JOSE stack of specifications before
they enter Last Call. The purpose of these comments is to try and figure
out if we can align multiple security, identity, and digital signature
initiatives.

My name is Manu Sporny, I'm the current chair at W3C for the RDFa,
JSON-LD, and Web Payments groups. I'm also a specification editor for
multiple Linked Data, Security, Identity, and JSON-based digital
signature specifications.

A few months ago, a number of the groups I'm involved with did a full
review the JOSE stack of specifications to ensure that we were not
duplicating work performed by the JOSE group. The result of that review
is available here:

http://manu.sporny.org/2013/sm-vs-jose/

A number of implementers involved in the Linked Data and Web Payments
work at W3C have chosen a different authentication, authorization, and
digital signature stack than the one that is being created here. This
decision came after much hand wringing and implementation feedback. We
used to be based on OpenID, and were headed down the JOSE route before
deciding to create an ecosystem that we believe is going to be simpler
for Web Developers to work with.

To be clear, this is not to imply that the JOSE or OpenID work is not
useful to a number of communities, but rather that it is not a stack
that lends itself well to the work we're doing in various groups at the
W3C and IETF. To give a very high-level outline of the different choices
we have made:

* JSON-LD spec for message format (instead of pure JSON)
* Secure Messaging spec for digital signatures (instead of JOSE)
* Persona for authn (instead of OpenID)
* HTTP Signatures & Secure Messaging for authz (instead of OpenID)

I don't want this to come across as some sort of attack on JOSE or
OpenID. It's not meant to be that at all. It's constructive criticism,
and we expect much of that to be returned on the spec stack that we have
proposed. We're not claiming to have all of the answers, we don't know
if the spec stack we've designed will stand the test of adoption over time.

What we do know is that our spec stack seems to be working better for
our use cases than the one we had designed previously based on
OpenID/JOSE. Keep in mind that there are a number of implementations
behind the technology that is described in the link above and the text
below, so these comments are not naive armchair commentary. :)

My hope is not that the JOSE/OpenID stack will be radically altered, but
that we'll be able to figure out where the points of integration are
between all of the specifications. For example, the Secure Messaging
specification expresses key data as PEM-encoded values. There is an
argument there to use the JWK key format instead.

I'll leave it there and look forward to responding to comments on this
thread.

The full-text of the review is listed below, for the purposes of long
term archival at the IETF and for those that want to respond inline.

------------------------------------------------------------------
Secure Messaging vs. Javascript Object Signing and Encryption

   The [1]Web Payments group at the World Wide Web Consortium (W3C)
   is currently performing a thorough analysis on the [2]MozPay API.
   The [3]first part of the analysis examined the contents of the
   payment messages . This is the second part of the analysis, which
   will focus on whether the use of the [4]Javascript Object Signing
   and Encryption (JOSE) group’s solutions to achieve message
   security is adequate, or if the Web Payment group’s solutions
   should be used instead.

The Contenders

   The IETF JOSE Working Group is actively standardizing the
   following specifications for the purposes of adding message
   security to JSON:

   [5]JSON Web Algorithms (JWA)
          Details the cryptographic algorithms and identifiers that
          are meant to be used with the JSON Web Signature (JWS),
          JSON Web Encryption (JWE), JSON Web Token (JWT), and JSON
          Web Key (JWK) specifications. For example, when specifying
          an encryption algorithm, a JSON key/value pair that has alg
          as the key may have HS256 as the value, which means HMAC
          using the SHA-256 hash algorithm.

   [6]JSON Web Key (JWK)
          Details a data structure that represents one or more
          cryptographic keys. If you need to express one of the many
          types of cryptographic key types in use today, this
          specification details how you do that in a standard way.

   [7]JSON Web Token (JWT)
          Defines a way of representing claims such as “Bob was born
          on November 15th, 1984″. These claims are digitally signed
          and/or encrypted using either the JSON Web Signature (JWS)
          or JSON Web Encryption (JWE) specifications.

   [8]JSON Web Encryption (JWE)
          Defines a way to express encrypted content using JSON-based
          data structures. Basically, if you want to encrypt JSON
          data so that only the intended receiver can read the data,
          this specification tells you how to do it in an
          interoperable way.

   [9]JSON Web Signature (JWS)
          Defines a way to digitally sign JSON data structures. If
          your application needs to be able to verify the creator of
          a JSON data structure, you can use this specification to do
          so.

   The W3C Web Payments group is actively standardizing a similar
   specification for the purpose of adding message security to JSON
   messages:

   [10]Secure Messaging (code named: HTTP Keys)
          Describes a simple, decentralized security infrastructure
          for the Web based on JSON, Linked Data, and public key
          cryptography. This system enables Web applications to
          establish identities for agents on the Web, associate
          security credentials with those identities, and then use
          those security credentials to send and receive messages
          that are both encrypted and verifiable via digital
          signatures.

   Both groups are relying on technology that has existed and been
   used for over a decade to achieve secure communications on the
   Internet (symmetric and asymmetric cryptography, public key
   infrastructure, X509 certificates, etc.). The key differences
   between the two have to do more with flexibility, implementation
   complexity, and how the data is published on the Web and used
   between systems.

Basic Differences

   In general, the JOSE group is attempting to create a
   flexible/generalized way of expressing cryptography parameters in
   JSON. They are then using that information and encrypting or
   signing specific data (called claims in the specifications).

   The Web Payments group’s specification achieves the same thing,
   but while not trying to be as generalized as the JOSE group.
   Flexibility and generalization tends to 1) make the ecosystem more
   complex than it needs to be for 95% of the use cases, 2) make
   implementations harder to security audit, and 3) make it more
   difficult to achieve interoperability between all implementations.
   The Secure Messaging specification attempts to outline a single
   best practice that will work for 95% of the applications out
   there. The 5% of Web applications that need to do more than the
   Secure Messaging spec can use the JOSE specifications. The Secure
   Messaging specification is also more Web-y. The more Web-y nature
   of the spec gives us a number of benefits, such as giving us a
   Web-scale public key infrastructure as a pleasant side-effect,
   that we will get into below.

JSON-LD Advantages over JSON

   Fundamentally, the Secure Messaging specification relies on the
   Web and [11]Linked Data to remove some of the complexity that
   exists in the JOSE specs while also achieving greater flexibility
   from a data model perspective. Specifically, the Secure Messaging
   specification utilizes Linked Data via a new standards-track
   technology called [12]JSON-LD to allow anyone to build on top of
   the core protocol in a decentralized way. JSON-LD data is
   fundamentally more Web-y than JSON data. Here are the benefits of
   using JSON-LD over regular JSON:
     * A universal identifier mechanism for JSON objects via the use
       of URLs.
     * A way to disambiguate JSON keys shared among different JSON
       documents by mapping them to URLs via a [13]context.
     * A standard mechanism in which a value in a JSON object may
       refer to a JSON object on a different document or site on the
       Web.
     * A way to associate datatypes with values such as dates and
       times.
     * The ability to annotate strings with their language. For
       example, the word ‘chat’ means something different in English
       and French and it helps to know which language was used when
       expressing the text.
     * A facility to express one or more directed graphs, such as a
       social network, in a single document. Graphs are the native
       data structure of the Web.
     * A standard way to map external JSON application data to your
       application data domain.
     * A deterministic way to generate a hash on JSON data, which is
       helpful when attempting to figure out if two data sources are
       expressing the same information.
     * A standard way to digitally sign JSON data.
     * A deterministic way to merge JSON data from multiple data
       sources.

   Plain old JSON, while incredibly useful, does not allow you to do
   the things mentioned above in a standard way. There is a valid
   argument that applications may not need this amount of
   flexibility, and for those applications, JSON-LD does not require
   any of the features above to be used and does not require the JSON
   data to be modified in any way. So people that want to remain in
   the plain ‘ol JSON bucket can do so without the need to jump into
   the JSON-LD bucket with both feet.

JSON Web Algorithms vs. Secure Messaging

   The JSON Web Algorithms specification details the cryptographic
   algorithms and identifiers that are meant to be used with the JSON
   Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Token
   (JWT), and JSON Web Key (JWK) specifications. For example, when
   specifying an encryption algorithm, a JSON key/value pair that has
   alg as the key may have HS256 as the value, which means HMAC using
   the SHA-256 hash algorithm. The specification is 70 pages long and
   is effectively just a collection of what values are allowed for
   each key used in JOSE-based JSON documents. The design approach
   taken for the JOSE specifications requires that such a document
   exists.

   The Secure Messaging specification takes a different approach.
   Rather than declare all of the popular algorithms and cryptography
   schemes in use today, it defines just one digital signature scheme
   ([14]RSA encryption with a SHA-256 hashing scheme), one encryption
   scheme ([15]128-bit AES with cyclic block chaining), and one way
   of expressing keys (as [16]PEM-formatted data). If placed into a
   single specification, like the JWA spec, it would be just a few
   pages long (really, just 1 page of actual content).

   The most common argument against the Secure Messaging spec, with
   respect to the JWA specification, is that it lacks the same amount
   of [17]cryptographic algorithm agility that the JWA specification
   provides. While this may seem like a valid argument on the
   surface, keep in mind that the core algorithms used by the Secure
   Messaging specification can be changed at any point to any other
   set of algorithms. So, the specification achieves algorithm
   agility while greatly reducing the need for a large 70-page
   specification detailing the allowable values for the various
   cryptographic algorithms. The other benefit is that since the
   cryptography parameters are outlined in a Linked Data vocabulary,
   instead of a process-heavy specification, that they can be added
   to at any point as long as there is community consensus. Note that
   while the vocabulary can be added to, thus providing algorithm
   agility if a particular cryptography scheme is weakened or broken,
   already defined cryptography schemes in the vocabulary must not be
   changed once the cryptography vocabulary terms become widely used
   to ensure that production deployments that use the older mechanism
   aren’t broken.

   Providing just one way, the best practice at the time, to do
   digital signatures, encryption, and key publishing reduces
   implementation complexity. Reducing implementation complexity
   makes it easier to perform security audits on implementations.
   Reducing implementation complexity also helps ensure better
   interoperability and more software library implementations, as the
   barrier to creating a fully conforming implementation is greatly
   reduced.

   The Web Payments group believes that new digital signature and
   encryption schemes will have to be updated every 5-7 years. It is
   better to delay the decision to switch to another primary
   algorithm as long as as possible (and as long as it is safe to do
   so). Delaying the cryptographic algorithm decision ensures that
   the group will be able to make a more educated decision than
   attempting to predict which cryptographic algorithms may be the
   successors to currently deployed algorithms.

   Bottom line: The Secure Messaging specification utilizes a much
   simpler approach than the JWA specification while supporting the
   same level of algorithm agility.

JSON Web Key vs. Secure Messaging

   The JSON Web Key (JWK) specification details a data structure that
   is capable of representing one or more cryptographic keys. If you
   need to express one of the many types of cryptographic key types
   in use today, JWK details how you do that in an standard way. A
   typical RSA public key looks like the following using the JWK
   specification:
{
  "keys": [{
    "kty":"RSA",
    "n": "0vx7agoe ... DKgw",
    "e":"AQAB",
    "alg":"RS256",
    "kid":"2011-04-29"
  }]
}

   A similar RSA public key looks like the following using the Secure
   Messaging specification:
{
  "@context": "https://w3id.org/security/v1",
  "@id": "https://example.com/i/bob/keys/1",
  "@type": "Key",
  "owner": "https://example.com/i/bob",
  "publicKeyPem": "-----BEGIN PRIVATE
KEY-----\nMIIBG0BA...OClDQAB\n-----END PRIVATE KEY-----\n"
}

   There are a number of differences between the two key formats.
   Specifically:
    1. The JWK format expresses key information by specifying the key
       parameters directly. The Secure Messaging format places all of
       the key parameters into a PEM-encoded blob. This approach was
       taken because it is easier for developers to use the PEM data
       without introducing errors. Since most Web developers do not
       understand what variables like dq (the second factor Chinese
       Remainder Theorem exponent parameter) or d (the Elliptic Curve
       private key parameter) are, the likelihood of transporting and
       publishing that sort of data without error is lower than
       placing all parameters in an opaque blob of information that
       has a clear beginning and end (-----BEGIN RSA PRIVATE
       KEY-----, and --- END RSA PRIVATE KEY ---)
    2. In the general case, the Secure Messaging key format assigns
       URL identifiers to keys and publishes them on the Web as
       JSON-LD, and optionally as RDFa. This means that public key
       information is discoverable and human and machine-readable by
       default, which means that all of the key parameters can be
       read from the Web. The JWK mechanism does assign a key ID to
       keys, but does not require that they are published to the Web
       if they are to be used in message exchanges. The JWK
       specification could be extended to enable this, but by
       default, doesn’t provide this functionality.
    3. The Secure Messaging format is also capable of specifying an
       identity that owns the key, which allows a key to be tied to
       an identity and that identity to be used for thinks like
       Access Control to Web resources and REST APIs. The JWK format
       has no such mechanism outlined in the specification.

   Bottom line: The Secure Messaging specification provides four
   major advantages over the JWK format: 1) the key information is
   expressed at a higher level, which makes it easier to work with
   for Web developers, 2) it allows key information to be discovered
   by deferencing the key ID, 3) the key information can be published
   (and extended) in a variety of Linked Data formats, and 4) it
   provides the ability to assign ownership information to keys.

JSON Web Tokens vs. Secure Messaging

   The JSON Web Tokens (JWT) specification defines a way of
   representing claims such as “Bob was born on November 15th, 1984″.
   These claims are digitally signed and/or encrypted using either
   the JSON Web Signature (JWS) or JSON Web Encryption (JWE)
   specifications. Here is an example of a JWT document:
{
  "iss": "joe",
  "exp": 1300819380,
  "http://example.com/is_root": true
}

   JWT documents contain keys that are public, such as iss and exp
   above, and keys that are private (which could conflict with keys
   from the JWT specification). The data format is fairly free-form,
   meaning that any data can be placed inside a JWT Claims Set like
   the one above.

   Since the Secure Messaging specification utilizes JSON-LD for its
   data expression mechanism, it takes a fundamentally different
   approach. There are no headers or claims sets in the Secure
   Messaging specification, just data. For example, the data below is
   effectively a JWT claims set expressed in JSON-LD:
{
  "@context": "http://json-ld.org/contexts/person",
  "@type": "Person",
  "name": "Manu Sporny",
  "gender": "male",
  "homepage": "http://manu.sporny.org/"
}

   Note that there are no keywords specific to the Secure Messaging
   specification, just keys that are mapped to URLs (to prevent
   collisions) and data. In JSON-LD, these keys and data are
   machine-interpretable in a standards-compliant manner (unlike JWT
   data), and can be merged with other data sources without the
   danger of data being overwritten or colliding with other
   application data.

   Bottom line: The Secure Messaging specifications use of a native
   Linked Data format removes the requirement for a specification
   like JWT. As far as the Secure Messaging specification is
   concerned, there is just data, which you can then digitally sign
   and encrypt. This makes the data easier to work with for Web
   developers as they can continue to use their application data
   as-is instead of attempting to restructure it into a JWT.

JSON Web Encryption vs. Secure Messaging

   The JSON Web Encryption (JWE) specification defines a way to
   express encrypted content using JSON-based data structures.
   Basically, if you want to encrypt JSON data so that only the
   intended receiver can read the data, this specification tells you
   how to do it in an interoperable way. A JWE-encrypted message
   looks like this:
{
  "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
  "unprotected": {"jku": "https://server.example.com/keys.jwks"},
  "recipients": [{
    "header": {
      "alg":"RSA1_5"
        "kid":"2011-04-29",
        "enc":"A128CBC-HS256",
        "jku":"https://server.example.com/keys.jwks"
      },
      "encrypted_key": "UGhIOgu ... MR4gp_A"
    }]
  }],
  "iv": "AxY8DCtDaGlsbGljb3RoZQ",
  "ciphertext": "KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
  "tag": "Mz-VPPyU4RlcuYv1IwIvzw"
}

   To decrypt this information, an application would retrieve the
   private key associated with the recipients[0].header, and then
   decrypt the encrypted_key. Using the decrypted encrypted_key
   value, it would then use the iv to decrypt the protected header.
   Using the algorithm provided in the protected header, it would
   then use the decrypted encrypted_key, iv, the algorithm specified
   in the protected header, and the ciphertext to retrieve the
   original message as a result.

   For comparison purposes, a Secure Messaging encrypted message
   looks like this:
{
  "@context": "https://w3id.org/security/v1",
  "@type": "EncryptedMessage2012",
  "data": "VTJGc2RH ... Fb009Cg==",
  "encryptionKey": "uATte ... HExjXQE=",
  "iv": "vcDU1eWTy8vVGhNOszREhSblFVqVnGpBUm0zMTRmcWtMrRX==",
  "publicKey": "https://example.com/people/john/keys/23"
}

   To decrypt this information, an application would use the private
   key associated with the publicKey to decrypt the encryptionKey and
   iv. It would then use the decrypted encryptionKey and iv to
   decrypt the value in data, retrieving the original message as a
   result.

   The Secure Messaging encryption protocol is simpler than the JWE
   protocol for three major reasons:
    1. The @type of the message, EncryptedMessage2012, encapsulates
       all of the cryptographic algorithm information in a
       machine-readable way (that can also be hard-coded in
       implementations). The JWE specification utilizes the protected
       field to express the same sort of information, which is
       allowed to get far more complicated than the Secure Messaging
       equivalent, leading to more complexity.
    2. Key information is expressed in one entry, the publicKey
       entry, which is a link to a machine-readable document that can
       express not only the public key information, but who owns the
       key, the name of the key, creation and revocation dates for
       the key, as well as a number of other Linked Data values that
       result in a full-fledged Web-based PKI system. Not only is
       Secure Messaging encryption simpler than JWE, but it also
       enables many more types of extensibility.
    3. The key data is expressed in a PEM-encoded format, which is
       expressed as a base-64 encoded blob of information. This
       approach was taken because it is easier for developers to use
       the data without introducing errors. Since most Web developers
       do not understand what variables like dq (the second factor
       Chinese Remainder Theorem exponent parameter) or d (the
       Elliptic Curve private key parameter) are, the likelihood of
       transporting and publishing that sort of data without error is
       lower than placing all parameters in an opaque blob of
       information that has a clear beginning and end (-----BEGIN RSA
       PRIVATE KEY-----, and --- END RSA PRIVATE KEY ---).

   The rest of the entries in the JSON are typically required for the
   encryption method selected to secure the message. There is not a
   great deal of difference between the two specifications when it
   comes to the parameters that are needed for the encryption
   algorithm.

   Bottom line: The major difference between the Secure Messaging and
   JWE specification has to do with how the encryption parameters are
   specified as well as how many of them there can be. The Secure
   Messaging specification expresses only one encryption mechanism
   and outlines the algorithms and keys external to the message,
   which leads to a reduction in complexity. The JWE specification
   allows many more types of encryption schemes to be used, at the
   expense of added complexity.

JSON Web Signatures vs. Secure Messaging

   The JSON Web Signatures (JWS) specification defines a way to
   digitally sign JSON data structures. If your application needs to
   be able to verify the creator of a JSON data structure, you can
   use this specification to do so. A JWS digital signature looks
   like the following:
{
  "payload": "eyJpc ... VlfQ",
  "signatures":[{
    "protected":"eyJhbGciOiJSUzI1NiJ9",
    "header": {
      "kid":"2010-12-29"
    },
    "signature": "cC4hi ... 77Rw"
  }]
}

   For the purposes of comparison, a Secure Messaging message and
   signature looks like the following:
{
  "@context": ["https://w3id.org/security/v1",
               "http://json-ld.org/contexts/person"]
  "@type": "Person",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "signature":
  {
    "@type": "GraphSignature2012",
    "creator": "http://example.org/manu/keys/5",
    "created": "2013-08-04T17:39:53Z",
    "signatureValue": "OGQzN ... IyZTk="
  }
}

   There are a number of stark differences between the two
   specifications when it comes to digital signatures:
    1. The Secure Messaging specification does not need to base-64
       encode the payload being signed. This makes it easier for a
       developer to see (and work with) the data that was digitally
       signed. Debugging signed messages is also simplified as
       special tools to decode the payload are unnecessary.
    2. The Secure Messaging specification does not require any header
       parameters for the payload, which reduces the number of things
       that can go wrong when verifying digitally signed messages.
       One could argue that this also reduces flexibility. The
       counter-argument is that different signature schemes can
       always be switched in by just changing the @type of the
       signature.
    3. The signer’s public key is available via a URL. This means
       that, in general, all Secure Messaging signatures can be
       verified by dereferencing the creator URL and utilizing the
       published key data to verify the signature.
    4. The Secure Messaging specification depends on a normalization
       algorithm that is applied to the message. This algorithm is
       non-trivial, typically implemented behind a JSON-LD library
       .normalize() method call. JWS does not require data
       normalization. The trade-off is simplicity at the expense of
       requiring your data to always be encapsulated in the message.
       For example, the Secure Messaging specification is capable of
       pointing to a digital signature expressed in RDFa on a website
       using a URL. An application can then dereference that URL,
       convert the data to JSON-LD, and verify the digital signature.
       This mechanism is useful, for example, when you want to
       publish items for sale along with their prices on a Web page
       in a machine-readable way. This sort of use case is not
       achievable with the JWS specification. All data is required to
       be in the message. In other words, Secure Messaging performs a
       signature on information that could exist on the Web where the
       JWS specification performs a signature on a string of text in
       a message.
    5. The JWS mechanism enables HMAC-based signatures while the
       Secure Messaging mechanism avoids the use of HMAC altogether,
       taking the position that shared secrets are typically a bad
       practice.

   Bottom line: The Secure Messaging specification does not need to
   encode its payloads, but does require a rather complex
   normalization algorithm. It supports discovery of signature key
   data so that signatures can be verified using standard Web
   protocols. The JWS specification is more flexible from an
   algorithmic standpoint and simpler from a signature verification
   standpoint. The downside is that the only data input format must
   be from the message itself and can’t be from an external Linked
   Data source, like an HTML+RDFa web page listing items for sale.

Conclusion

   The Secure Messaging and JOSE designs, while attempting to achieve
   the same basic goals, deviate in the approaches taken to
   accomplish those goals. The Secure Messaging specification
   leverages more of the Web with its use of a Linked Data format and
   URLs for identifying and verifying identity and keys. It also
   attempts to encapsulate a single best practice that will work for
   the vast majority of Web applications in use today. The JOSE
   specifications are more flexible in the type of cryptographic
   algorithms that can be used which results in more low-level
   primitives used in the protocol, increasing complexity for
   developers that must create interoperable JOSE-based applications.

   From a specification size standpoint, the JOSE specs weigh in at
   225 pages, the Secure Messaging specification weighs in at around
   20 pages. This is rarely a good way to compare specifications, and
   doesn’t always result in an apples to apples comparison. It does,
   however, give a general idea of the amount of text required to
   explain the details of each approach, and thus a ballpark idea of
   the complexity associated with each specification. Like all
   specifications, picking one depends on the use cases that an
   application is attempting to support. The goal with the Secure
   Messaging specification is that it will be good enough for 95% of
   Web developers out there, and for the remaining 5%, there is the
   JOSE stack.

References

   1. http://www.w3.org/community/webpayments/
   2. https://wiki.mozilla.org/WebAPI/WebPayment
   3. http://manu.sporny.org/2013/mozpay-analysis/
   4. http://tools.ietf.org/wg/jose/
   5. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms
   6. http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-key/
   7. http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
   8. http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption
   9. http://tools.ietf.org/wg/jose/draft-ietf-jose-json-web-signature/
  10. https://payswarm.com/specs/source/http-keys/
  11. http://www.youtube.com/watch?v=4x_xzT5eF5Q
  12. http://www.youtube.com/watch?v=vioCbTo3C-4
  13. http://json-ld.org/spec/latest/json-ld/#the-context
  14. https://payswarm.com/specs/source/vocabs/security#GraphSignature2012
  15. https://payswarm.com/specs/source/vocabs/security#EncryptedMessage
  16. https://payswarm.com/specs/source/vocabs/security#privateKeyPem
  17. http://msdn.microsoft.com/en-us/magazine/ee321570.aspx

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

---

From: Harry Halpin <[email-masked]>
Date: Thu, 12 Dec 2013 00:05:08 +0100

Just to be clear, while we at W3C appreciate Manu's very hard work as a 
chair and editor (and very active volunteer), these comments are not 
authorized by as "official" W3C comments, as he represents himself and 
his Blacksburg, Virginia-based startup, Digital Bazaar.

To be precise, Manu is chair of the Web Payments Community Group where 
he represents Digital Bazaar, and the Community Group may have also 
endorsed these comments (although W3C defines no process for this). 
These Community Groups are *not* Working Groups, that go through W3C 
management approval and have to be voted on by the Advisory Committee of 
W3C members. Anyone with three individual supporters can create a 
Community Group on any topic they desire without permission of the W3C 
[1]. We consider Community Groups ways to harvest ideas that could be 
useful for Recommendations later down than the line.  Manu is also 
authorized chair of the RDFa Working Group and JSON-LD is a 
serialization from the RDF Working Group, where he is authorized as one 
of the editors of the JSON-LD specification.

The W3C has in not endorsed the Web Payments Community Group's specs as 
any kind of recommendation, and in particular the W3C has not endorsed 
the specs on Secure Messaging and HTTP Signatures mentioned below. This 
does not preclude endorsement in the future, although so far we have in 
Rec-track worked aligned with the IETF.  Persona is Mozilla work. The 
two specs he mentions that the W3C has endorsed are both Semantic Web 
specifications:   JSON-LD, which is currently a Proposed Recommendation, 
which is useful to the Semantic Web community so that the achieve 
interoperability with JSON, as well as RDFa, which is a Recommendation 
for embedding the Semantic Web format RDF into HTML.

In my authorized role as Web Crypto staff contact, we are aligning Web 
Crypto with JOSE keys and using standard JSON, not yet JSON-LD, to pass 
around data in the Web Crypto API. The future of Web Payments will be 
discussed at a workshop that everyone is invited to in March in Paris 
where representation from the JOSE WG would be appreciated, and I 
believe Manu will be there as well [3]

Just to clarify any confusion as regards Manu's relationship with the 
W3C. I do hope you can respond to his comments.

   cheers,
      harry

[1] http://www.w3.org/community/
[2] http://www.w3.org/TR/json-ld/
[3] http://www.w3.org/2013/10/payments/

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 11 Dec 2013 19:08:58 -0500

Also as a clarification, this topic came up at the Shenzhen W3C meeting. 
Following an additional conversation after the TPAC, Richard Barnes and 
I asked Manu to post his discussion to the JOSE WG mailing list for 
further discussion by the community.

Karen

On 12/11/13 6:05 PM, Harry Halpin wrote:
> Just to be clear, while we at W3C appreciate Manu's very hard work as 
> a chair and editor (and very active volunteer), these comments are not 
> management approval and have to be voted on by the Advisory Committee 
> of W3C members. Anyone with three individual supporters can create a 
> serialization from the RDF Working Group, where he is authorized as 
> one of the editors of the JSON-LD specification.
>
> The W3C has in not endorsed the Web Payments Community Group's specs 
> as any kind of recommendation, and in particular the W3C has not 
> endorsed the specs on Secure Messaging and HTTP Signatures mentioned 
> below. This does not preclude endorsement in the future, although so 
> far we have in Rec-track worked aligned with the IETF.  Persona is 
> Mozilla work. The two specs he mentions that the W3C has endorsed are 
> both Semantic Web specifications:   JSON-LD, which is currently a 
> Proposed Recommendation, which is useful to the Semantic Web community 
> so that the achieve interoperability with JSON, as well as RDFa, which 
> is a Recommendation for embedding the Semantic Web format RDF into HTML.
>
> Crypto with JOSE keys and using standard JSON, not yet JSON-LD, to 
> pass around data in the Web Crypto API. The future of Web Payments 
> will be discussed at a workshop that everyone is invited to in March 
> in Paris where representation from the JOSE WG would be appreciated, 
> and I believe Manu will be there as well [3]
>
>>    14. 
>> https://payswarm.com/specs/source/vocabs/security#GraphSignature2012
>>    15. 
>> https://payswarm.com/specs/source/vocabs/security#EncryptedMessage
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Luke Howard <[email-masked]>
Date: Thu, 12 Dec 2013 12:00:14 +1100

>   successors to currently deployed algorithms.

I'd rather have algorithm agility in the spec and a separate profile for a particular use case (which can, say, require only one algorithm being mandatory to implement) than baking the algorithm in the spec. And PEM-inside-JSON just seems a bit ugly to me -- I don't really buy the implementation complexity argument when there are already plenty of libraries that will do the heavy lifting for you.

Just my 2c.

-- Luke

---

From: John Bradley <[email-masked]>
Date: Wed, 11 Dec 2013 22:38:19 -0300

Some of the comments are based on earlier drafts.

As an example JWK supports PEM encoded certificates and certificate chains as well as raw keys.  They can both share the same "kid" as alternate representations.

There are issues with using x.509 certificate representations in some circumstances where you are using self signed keys rather than a pkix trust model.  
Some will likely observer that making PEM the only format and relying on certificate processing is fine if you are in a pkix/ca world like the payment industry.   
Others may not find that path as attractive.

It is interesting feedback, I understand the argument for simplicity, however the desire to serve broad communities is something that needs to be strongly considered.

I also didn't see anything on requiring integrity for encryption in the comparison, but I can't imagine that they would only support AES-CBC with it's well understood security problems as the ony encryption option.   I will need to look at the actual spec.

There are ways to do a number of things to support the SM trust model in JOSE.
"jku":"http://example.org/manu/keys/5"   vs "creator": "http://example.org/manu/keys/5"

In JOSE there is a logical separation between the identity of the signer and the location of the key.  In SM for simplicity identity and location may the same thing.

John B.

On Dec 11, 2013, at 9:08 PM, Karen O'Donoghue <[email-masked]> wrote:

> Also as a clarification, this topic came up at the Shenzhen W3C meeting. Following an additional conversation after the TPAC, Richard Barnes and I asked Manu to post his discussion to the JOSE WG mailing list for further discussion by the community.
> 
> Karen
> 
>> Just to be clear, while we at W3C appreciate Manu's very hard work as a chair and editor (and very active volunteer), these comments are not authorized by as "official" W3C comments, as he represents himself and his Blacksburg, Virginia-based startup, Digital Bazaar.
>> 
>> To be precise, Manu is chair of the Web Payments Community Group where he represents Digital Bazaar, and the Community Group may have also endorsed these comments (although W3C defines no process for this). These Community Groups are *not* Working Groups, that go through W3C management approval and have to be voted on by the Advisory Committee of W3C members. Anyone with three individual supporters can create a Community Group on any topic they desire without permission of the W3C [1]. We consider Community Groups ways to harvest ideas that could be useful for Recommendations later down than the line.  Manu is also authorized chair of the RDFa Working Group and JSON-LD is a serialization from the RDF Working Group, where he is authorized as one of the editors of the JSON-LD specification.
>> 
>> The W3C has in not endorsed the Web Payments Community Group's specs as any kind of recommendation, and in particular the W3C has not endorsed the specs on Secure Messaging and HTTP Signatures mentioned below. This does not preclude endorsement in the future, although so far we have in Rec-track worked aligned with the IETF.  Persona is Mozilla work. The two specs he mentions that the W3C has endorsed are both Semantic Web specifications:   JSON-LD, which is currently a Proposed Recommendation, which is useful to the Semantic Web community so that the achieve interoperability with JSON, as well as RDFa, which is a Recommendation for embedding the Semantic Web format RDF into HTML.
>> 
>> In my authorized role as Web Crypto staff contact, we are aligning Web Crypto with JOSE keys and using standard JSON, not yet JSON-LD, to pass around data in the Web Crypto API. The future of Web Payments will be discussed at a workshop that everyone is invited to in March in Paris where representation from the JOSE WG would be appreciated, and I believe Manu will be there as well [3]
>> 
>> Just to clarify any confusion as regards Manu's relationship with the W3C. I do hope you can respond to his comments.
>> 
>>  cheers,
>>     harry
>> 
>>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 12 Dec 2013 05:03:44 +0100

> out if we can align multiple security, identity, and digital signature

I have one comment to this.  SM (Secure Messaging) differs from its JOSE
counterpart in several ways. One difference I believe is particularly
significant is SM's ability to sign data "as is" rather than requiring
conversion of the payload to base64.

That is, regardless of the success of the JOSE stack, there will undoubtedly
be important applications relying on information-rich data (like Web payments)
which will deploy clear text signatures.  Completely independent (and unaware)
of Manu's work I recently designed a "brutally" scaled-down JSON-version of
W3C's XML DSig which is another take on this subject:

http://webpki.org/papers/keygen2/doc/jcs.html
https://mobilepki.org/jcs

To get some feeling for its usage you may take a peek at:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/sks-api-arch.pdf#page=23

I can't imagine that anybody developing such a cool system [:-)] would consider
base64-encoded messages unless it was found to be a necessity.  The actual
implementation (which is extremely compact), shows that clear text signatures
can be close to trivial if you design the parser with that in mind from the beginning:
https://code.google.com/p/openkeystore/source/browse/#svn%2Flibrary%2Ftrunk%2Fsrc%2Forg%2Fwebpki%2Fjson

Cheers,
Anders

---

From: Dirkjan Ochtman <[email-masked]>
Date: Thu, 12 Dec 2013 09:06:33 +0100

On Thu, Dec 12, 2013 at 12:05 AM, Harry Halpin <[email-masked]> wrote:
> Persona is Mozilla work.

Note that Persona *does* build on the JOSE standards, so Web Payments
at least relies on the JOSE work indirectly.

(And thanks for providing some context, Harry.)

Cheers,

Dirkjan

---

From: Manu Sporny <[email-masked]>
Date: Thu, 12 Dec 2013 08:57:17 -0500

On 12/11/2013 08:00 PM, Luke Howard wrote:
> I'd rather have algorithm agility in the spec and a separate profile
>  for a particular use case (which can, say, require only one 
> algorithm being mandatory to implement) than baking the algorithm in 
> the spec.

There is the equivalent to algorithm agility in SM, read the comments in
the blog post for details:

http://manu.sporny.org/2013/sm-vs-jose/#comment-2763

> And PEM-inside-JSON just seems a bit ugly to me

Yes, it's ugly, but it also ensures that when Web developers copy/paste
the public keys around (which they will), they won't accidentally
truncate the key data (or if they do, it'll be clear that they did).

This was one of the areas that we could align with the JOSE specs, on
key format. However, it seems as if PEM-encoded keys are less dangerous
to pass around among Web developers than the way they're expressed in JOSE.

> I don't really buy the implementation complexity argument when there 
> are already plenty of libraries that will do the heavy lifting for 
> you.

It's not just implementation complexity for library implementers, which
is bad. It's also implementation complexity for the entire stack, all
the way up to the application layer. It's also cognitive complexity for
the developers using the libraries, they will feel like they have to go
off and understand all of those key parameters when 90%+ of the time,
the defaults will be fine.

The question we asked ourselves wrt. algorithm agility was: Is this
algorithm agility feature buying anything significant?

The answer, each time we asked the question, was no. For 90%+ of the use
cases, there is typically a set of defaults that most developers use.
Look at the way HTTPS is configured on most Web servers - developers and
sysadmins use the defaults 90%+ of the time. The same could easily be
applied to crypto parameters as the only people that truly care about
being able to fiddle with those parameters are security/crypto folks.

-- manu

---

From: Manu Sporny <[email-masked]>
Date: Thu, 12 Dec 2013 11:19:33 -0500

> Some of the comments are based on earlier drafts.

Yes, the blog post was created in August 2013, the research for the post
was done in July 2013, and the latest specs at that time were used.

> There are issues with using x.509 certificate representations in some
> circumstances where you are using self signed keys rather than a pkix
> trust model. Some will likely observer that making PEM the only 
> format and relying on certificate processing is fine if you are in a
>  pkix/ca world like the payment industry.

Keep in mind that the only place we use PEM encoding is for the
expression of public and private keys. We don't use PEM anywhere else in
the stack, IIRC.

> Others may not find that path as attractive.

Others like who? :) I'm sure there are others, and I want to make sure
we're not missing out on a large use case. Let me reiterate that we're
not greatly interested in corner cases with the SM specs. If there are
corner cases that need to be addressed, the JOSE stack is capable of
addressing those corner cases.

> It is interesting feedback, I understand the argument for simplicity,
> however the desire to serve broad communities is something that needs
> to be strongly considered.

I think it would be more productive to understand which "broad
community" isn't being considered with the SM work and whether the
addition of complexity to the specification outweighs the benefit of
supporting that community.

> I also didn't see anything on requiring integrity for encryption in 
> the comparison, but I can't imagine that they would only support 
> AES-CBC with it's well understood security problems as the ony 
> encryption option.   I will need to look at the actual spec.

In general, we will support the minimum set of encryption methods
necessary to make the security community happy (ideally, there would be
one, which would be deprecated and updated every few years).

The exact suite and parameters isn't as important as trying to ensure
that there is just one mechanism every few years. It simplifies the
range of input that applications need to deal with and test. It
simplifies the number of parameters that developers need to deal with
and understand.

> There are ways to do a number of things to support the SM trust model
> in JOSE. "jku":"http://example.org/manu/keys/5"   vs "creator":
> "http://example.org/manu/keys/5"
> 
> In JOSE there is a logical separation between the identity of the 
> signer and the location of the key.  In SM for simplicity identity 
> and location may the same thing.

No, that's not the case in SM. The identity and the keys are logically
separated.

Here's my test identity (curl to get the JSON-LD representation):

https://dev.payswarm.com/i/manu

Here's one of the keys associated with my test identity:

https://dev.payswarm.com/i/manu/keys/17

The reason we use the "creator" terminology is because the entity that
created the signature is the key:

http://dublincore.org/documents/dces/#creator

There is a link from the key to the owner of that key (this command will
give you the JSON-LD representation for that key):

curl "https://dev.payswarm.com/i/manu/keys/17"

-- manu

---

From: "Manger, James" <[email-masked]>
Date: Tue, 17 Dec 2013 10:34:51 +1100

There might be some nice ideas in the JSON-LD-based Secure Messaging. However, a crypto spec that uses encryption without authentication (no AEAD), uses raw CBC mode, thinks CBC stands for *cyclic* block chaining, puts "BEGIN *PRIVATE* KEY" in a field named publicKeyPem, requires RDF Graph Normalization that seems far removed from JSON, etc does not feel like a great basis.

--
James Manger

> -----Original Message-----
> From: jose [mailto:[email-masked]] On Behalf Of Manu Sporny
> Sent: Thursday, 12 December 2013 8:44 AM
> To: JOSE WG
> Subject: [jose] Review Comments: Web Payments, Secure Messaging, and
> JOSE
> 
> Hi all,
> 
...
> KEY-----\nMIIBG0BA...OClDQAB\n-----END PRIVATE KEY-----\n"
...

---

From: Manu Sporny <[email-masked]>
Date: Mon, 23 Dec 2013 16:30:21 -0500

On 12/11/2013 11:03 PM, Anders Rundgren wrote:
> I have one comment to this.  SM (Secure Messaging) differs from its
> JOSE counterpart in several ways. One difference I believe is
> particularly significant is SM's ability to sign data "as is" rather
> than requiring conversion of the payload to base64.

Good point, as we found base64 encoding the payload (while an easier
solution) to be more difficult to debug when dealing with typical Web
stack debugging tools and messages. That is, this pushes the burden onto
the Web developer when the burden should be on the implementers of the
digital signature mechanism (SM / JOSE).

For example, when transmitting and receiving signed data, a developer
would have to do an extra step of base64 decoding the payload to see the
data that was sent while trying to debug an issue with the contents of
the payload. While this sounds like a fairly benign issue, the process
would have to be done many, many times throughout the day leading to
mental fatigue.

You could make the argument that tools will be developed for this
requirement. The counter-argument being that it would be better to
eliminate the tool than require more applications to be added to the
stack of tools required to do Web development.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/

---

From: Manu Sporny <[email-masked]>
Date: Mon, 23 Dec 2013 16:32:29 -0500

On 12/12/2013 03:06 AM, Dirkjan Ochtman wrote:
> Note that Persona *does* build on the JOSE standards, so Web
> Payments at least relies on the JOSE work indirectly.

We're considering dropping support for the use of JOSE in the Persona
implementations that we're going to do for the Web Payments work. We are
probably going to support both in the beginning, but see if folks will
want to migrate to SM in the long run for the Web Payments use cases.

-- manu

---

From: Manu Sporny <[email-masked]>
Date: Mon, 23 Dec 2013 17:31:14 -0500

On 12/16/2013 06:34 PM, Manger, James wrote:
> There might be some nice ideas in the JSON-LD-based Secure
> Messaging. However, a crypto spec that uses encryption without
> authentication (no AEAD), uses raw CBC mode,

The spec has been updated, it uses GCM now.

We thought picking the final authenc algorithm now would be premature.
We had considered that the side-channel attacks would be a problem for
reviewers but hadn't updated the spec because we wanted to have a more
detailed discussion w/ the security community before picking an authenc
algorithm. We may not pick GCM in the end, but just picked that one
right now so that this wouldn't continue to be a distraction.

The spec is rough, implementations lead it by many months. What we're
trying to get feedback on right now is the overall approach. We'll put
more work into polishing up the spec as soon as we've determined that
there are no serious issues with the approach.

> thinks CBC stands for *cyclic* block chaining,

A typo in the spec, fixed.

> puts "BEGIN *PRIVATE* KEY" in a field named publicKeyPem,

A typo in the blog post, fixed.

> requires RDF Graph Normalization that seems far removed from JSON,

We actually started out with a JSON-based normalization algorithm. We
quickly discovered that we could generalize the normalization to not
just JSON, but a general graph-based data model. This is useful when
you're exchanging Linked Data like the Web Payments work does. We are
able to use the same normalization scheme for a variety of Linked Data
languages (JSON-LD, RDFa, Microdata, Turtle, NQuads, etc.). So, one
could express the data in HTML5+RDFa (via a web page) or JSON-LD (via a
REST API) and share the same digital signature since the sig is on the
information and not the structure of the JSON message.

That's not to say that the normalization algorithm couldn't be switched
out pretty easily, but to date we haven't had a need for another one
that is JSON specific. If that need arises, the only modification to the
Secure Messaging spec that would be needed would be to define the @type
of that normalization algorithm. For example:

"signature":
{
  "@type": "JsonSignature2014", <-- this is the only change necessary
  "creator": "http://example.org/manu/keys/5",
  "created": "2013-08-04T17:39:53Z",
  "signatureValue": "OGQzN ... IyZTk="
}

JSON-LD[1] expresses Linked Data[2]. The data model is a graph of
information (like the Web). We digitally sign that information at the
data model layer, not the JSON syntax layer. Doing so allows us to use
the same digital signature across a variety of syntaxes. It's more
flexible than just hard coding the normalization algorithm to JSON.

-- manu

[1] http://www.youtube.com/watch?v=vioCbTo3C-4
[2] http://www.youtube.com/watch?v=4x_xzT5eF5Q

---

From: Luke Howard <[email-masked]>
Date: Tue, 24 Dec 2013 09:37:30 +1100

> want to migrate to SM in the long run for the Web Payments use cases.

Forking the Persona specification and code because base64 is putatively harder to debug seems a high price to pay -- just my 2c.

-- Luke

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 24 Dec 2013 00:22:49 +0100

> Forking the Persona specification and code because base64 is putatively harder to debug seems a high price to pay -- just my 2c.

I can't imagine base64-encoding cool messages like the following (unless it was absolutely necessary):

https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.ProvisioningInitializationResponse

It is proven beyond doubt that JSON canonicalization can be a breeze using a _proper_ parser where this was taken in consideration from the start.

My parser is less than 400 lines:
https://code.google.com/p/openkeystore/source/browse/library/trunk/src/org/webpki/json/JSONParser.java

Anders

---

From: Manu Sporny <[email-masked]>
Date: Mon, 23 Dec 2013 20:13:27 -0500

On 12/23/2013 05:37 PM, Luke Howard wrote:
>> We're considering dropping support for the use of JOSE in the 
>> Persona implementations that we're going to do for the Web Payments
>> work. We are probably going to support both in the beginning, but
>> see if folks will want to migrate to SM in the long run for the Web
>> Payments use cases.
> 
> Forking the Persona specification and code because base64 is 
> putatively harder to debug seems a high price to pay -- just my 2c.

If the base64 issue was the only issue, I'd agree with you. However, the
review that was done outlined a number of other issues[1] that IMHO,
when combined with the goals of Persona, make JOSE a questionable fit.
JOSE was picked at the time because there really wasn't a viable
alternative. Now that there may be one, things might change.

Persona doesn't seem to need any of the more complex functionality
brought by JOSE (resulting in unnecessarily complex and hard to debug
messages). Secure Messaging could achieve the same level of
functionality, more simply, for Web developers.

-- manu

[1] http://manu.sporny.org/2013/sm-vs-jose/

---

From: Luke Howard <[email-masked]>
Date: Tue, 24 Dec 2013 12:59:42 +1100

> alternative. Now that there may be one, things might change.

Off-topic for this mailing list, but I'd certainly be interested to see a discussion on dev-identity about this, particularly as the Persona team are (last I heard) busy aligning with the current JOSE data formats.

> functionality, more simply, for Web developers.

In the document you refer to, it's unclear where the signature for EncryptedMessage2012 is placed -- is there a specification for this?

-- Luke

---

From: Axel Nennker <[email-masked]>
Date: Tue, 24 Dec 2013 09:20:22 +0100

Hi,
this document describes the current Persona formats and the differences to
JOSE.
My understanding from the dev-identity emails is that Persona and FxA want
to align with JOSE and get rid of the differences:
https://github.com/djc/id-specs/blob/prod/browserid/json-formats.md

As a developer I don't buy the Anti-base64-encoding / simplicity argument
because I only have to output the decoded message to my payment-server's
logs. I never sniff the messages from the wire which  would be much harder
because they come through an SSL channel anyway.

I think that canonicalization / normalization of the to-be-signed payment
message is a HUGE mistake. That was a major pain with xmldsig in the past.
base64 encoding stuff and working on that is MUCH better for
interoperability.

-Axel

2013/12/24 Luke Howard <[email-masked]>

> Off-topic for this mailing list, but I'd certainly be interested to see a
> discussion on dev-identity about this, particularly as the Persona team are
> (last I heard) busy aligning with the current JOSE data formats.
>
> In the document you refer to, it's unclear where the signature for
> EncryptedMessage2012 is placed -- is there a specification for this?
>
> -- Luke

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Dec 2013 01:58:01 -0700

On 12/24/13 1:20 AM, Axel Nennker wrote:

> I think that canonicalization / normalization of the to-be-signed
> payment message is a HUGE mistake. That was a major pain with xmldsig in
> the past. base64 encoding stuff and working on that is MUCH better for
> interoperability.

A big +1 to that. Going down the canonicalization road can only harm
interoperability.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 24 Dec 2013 10:07:49 +0100

> A big +1 to that. Going down the canonicalization road can only harm

I think you rather need to abandon the junk-parsers.

https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Canonicalization_and_Signature_Validation

Less than 400 lines of pretty down-to-earth code and algorithms can hardly stop progress!

Anders

---

From: Manu Sporny <[email-masked]>
Date: Fri, 27 Dec 2013 13:51:29 -0500

On 12/24/2013 03:20 AM, Axel Nennker wrote:
> this document describes the current Persona formats and the 
> differences to JOSE. My understanding from the dev-identity emails
> is that Persona and FxA want to align with JOSE and get rid of the 
> differences: 

Yes, I think it's fair to say that the Persona team's plan is to align
with the JOSE specs. However, the identity community is larger than the
Persona team and we've raised the possibility that we'll be challenging
the notion that identity solutions on the Web should utilize the JOSE
specs for the reasons outlined in the review.

> As a developer I don't buy the Anti-base64-encoding / simplicity 
> argument because I only have to output the decoded message to my 
> payment-server's logs. I never sniff the messages from the wire
> which would be much harder because they come through an SSL channel 
> anyway.

You are looking at it from the standpoint of having access to the
server-side. Many web developers spend a large chunk of their time
interfacing with services from the client side, where they don't have
access to the server side (interfacing w/ Twitter, Facebook, Google
services, etc.). Many of these developers use the built-in browser tools
to do development, and would be hampered by seeing large chunks of
non-binary base64 data coming across the wire.

On 12/24/2013 03:20 AM, Axel Nennker wrote:
> payment message is a HUGE mistake. That was a major pain with
> xmldsig in the past. base64 encoding stuff and working on that is
> MUCH better for interoperability.
> A big +1 to that. Going down the canonicalization road can only harm

One of the major reasons it was a big pain in XMLDSIG is because you
could express the same message in a bunch of different syntactic ways.
Another reason was because of namespace injection. We do not attempt to
canonicalize the JSON message due to the variation in serialization wrt.
JSON processors. Rather, we canonicalize at the data model layer using a
very simple syntax. Thus, we don't fall into the same trap that XMLDSIG did.

The major issues with XMLDSIG are not issues with the canonicalization
mechanism used for the SM spec. We have 3 interoperable implementations
at this point and a fairly expansive test suite to ensure compliance
with the digital signature algorithm. To date, we haven't hit upon the
same issues that XMLDSIG did.

Perhaps you could elaborate on why the approach that we took, which is
very different from XMLDSIG, is going to harm interoperability. The
current arguments put forward for "canonicalization is bad" assume that
we took the same path that XMLDSIG took, which is an uninformed starting
point.

-- manu