Re: [jose] A modest proposal for JSON-izing JW*

Mike Jones <Michael.Jones@microsoft.com> Wed, 06 February 2013 20:35 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B4021F8893 for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 12:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zptRgIh-NDGR for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 12:35:23 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 91A3721F8809 for <jose@ietf.org>; Wed, 6 Feb 2013 12:35:22 -0800 (PST)
Received: from BY2FFO11FD005.protection.gbl (10.1.15.202) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.609.9; Wed, 6 Feb 2013 20:35:19 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Wed, 6 Feb 2013 20:35:19 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Wed, 6 Feb 2013 20:34:52 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Thread-Topic: [jose] A modest proposal for JSON-izing JW*
Thread-Index: AQHOBKhA4q7DN6ROrUmM6hkX64rTbZhtR3PA
Date: Wed, 06 Feb 2013 20:34:52 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367418261@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <i6en5euln6sqjov9s38h85ax.1360182392441@email.android.com>
In-Reply-To: <i6en5euln6sqjov9s38h85ax.1360182392441@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.37]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367418261TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(512874001)(51856001)(50986001)(74662001)(76482001)(79102001)(59766001)(47736001)(54356001)(80022001)(47976001)(44976002)(56816002)(55846006)(49866001)(4396001)(31966008)(33656001)(53806001)(54316002)(74502001)(47446002)(77982001)(16406001)(63696002)(20776003)(46102001)(56776001)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB027; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0749DC2CE6
Cc: Richard Barnes <rlb@ipv.sx>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] A modest proposal for JSON-izing JW*
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 20:35:25 -0000

We already have it in a separate pair of drafts that are ready for submission as working group drafts once the rechartering is complete.  That was what the working group decided in Atlanta to have happen.  And as I understand it, the rechartering probably won’t take much longer.

What’s most developer-friendly depends upon the developer’s use cases.  If they’re only using the compact serialization (which for instance, Mozilla Persona, OpenID Connect, and I believe Dick Hardt’s application all do), they’re more developer-friendly without also making the developer skip the parts about the JSON serialization.  If they’re using the JSON serialization, then yes, combining them would be more friendly for those developers.

As I’d said in a private thread with Richard, I’m fine with the working group deciding either to combine or not combine them.  But given that the different choices make things easier/harder for different sets of developers, I believe that any decision to combine them should be well-discussed by the working group first, and not just done on a whim.

                                                            -- Mike

From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Wednesday, February 06, 2013 12:27 PM
To: Mike Jones
Cc: Richard Barnes; jose@ietf.org
Subject: Re: [jose] A modest proposal for JSON-izing JW*

Why don't we address the issue right away (as Richard proposed) instead of postponing it to yet another draft?

Hannes

Sent from my ASUS Pad

Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
I’ll note that these are nearly identical to the JSON Serialization encodings already specified in http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-04 and http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-04, other than you’re precluding multiple recipients.  The syntax:

     {"recipients":[
       {"header":"<header 1 contents>",
        "signature":"<signature 1 contents>"},
       ...
       {"header":"<header N contents>",
        "signature":"<signature N contents>"}],
      "payload":"<payload contents>"
     }

really isn’t far from what you’re proposing below.  It just has an array of per-recipient header fields, since accommodating multiple recipients is also a working group goal.

Once the rechartering is done, we’ll have working group JSON serialization specifications.  It’s a separate question whether to combine the compact and JSON serializations into the same document or to leave them separate.  The revised charter will allow us to do either.

                                                            -- Mike

From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 06, 2013 11:29 AM
To: jose@ietf.org<mailto:jose@ietf.org>
Subject: [jose] A modest proposal for JSON-izing JW*

Dear JOSE,

tl;dr: Let's please add a simple JSON encoding to the base JW* specs.

I've been complaining for a while that the JW* documents aren't JSON, and that the JSON serialization documents are too complex (because of the integrity check issues).  So I thought it was about time that I made an actual proposal for encoding the base JOSE object as JSON objects.  The approach would be essentially the same as in the JSON serialization documents, except with a focus on single objects.

JWE and JWS objects currently have the following form

jws = header.data.signature
jwe = header.key.iv.ciphertext.mac

The JSON encoding of a JWE/JWS would just take each of these Base64-encoded pieces and assign them a name in a JSON structure.

jws = {
    "header": header,
    "data": data,
    "signature": signature
}

jwe = {
    "header": header,
    "key": key,
    "iv": iv,
    "data": ciphertext,
    "mac": mac
}

It seems to me that these encodings are simple enough that they could be handled in a short section, in parallel to what I would call the "text serialization" in the current documents.  So I would like to propose that they be added to the base JWE and JWS documents.

Thanks,
--Richard