Re: [jose] Should we delete the "typ" header field

Anthony Nadalin <tonynad@microsoft.com> Thu, 30 May 2013 18:55 UTC

Return-Path: <tonynad@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 BA41F21F86C4 for <jose@ietfa.amsl.com>; Thu, 30 May 2013 11:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.534
X-Spam-Level:
X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjR7QEj1SsEu for <jose@ietfa.amsl.com>; Thu, 30 May 2013 11:55:47 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6B52021F909A for <jose@ietf.org>; Thu, 30 May 2013 11:55:47 -0700 (PDT)
Received: from BY2FFO11FD018.protection.gbl (10.1.15.204) by BY2FFO11HUB021.protection.gbl (10.1.14.108) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 30 May 2013 18:54:40 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD018.mail.protection.outlook.com (10.1.14.106) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Thu, 30 May 2013 18:54:40 +0000
Received: from CO9EHSOBE012.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 30 May 2013 18:54:33 +0000
Received: from mail38-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 May 2013 18:54:33 +0000
Received: from mail38-co9 (localhost [127.0.0.1]) by mail38-co9-R.bigfish.com (Postfix) with ESMTP id 31CA3C00E8 for <jose@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Thu, 30 May 2013 18:54:33 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371Ic85fh1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kz97hz1033IL17326ah18c673h1954cbh8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh17ej9a9j1155h)
Received-SPF: softfail (mail38-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB190; H:BY2PR03MB189.namprd03.prod.outlook.com; LANG:en;
Received: from mail38-co9 (localhost.localdomain [127.0.0.1]) by mail38-co9 (MessageSwitch) id 1369940070869177_2853; Thu, 30 May 2013 18:54:30 +0000 (UTC)
Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.228]) by mail38-co9.bigfish.com (Postfix) with ESMTP id D1C1D68004C; Thu, 30 May 2013 18:54:30 +0000 (UTC)
Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 May 2013 18:54:30 +0000
Received: from BY2PR03MB190.namprd03.prod.outlook.com (10.242.36.141) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 30 May 2013 18:54:28 +0000
Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB190.namprd03.prod.outlook.com (10.242.36.141) with Microsoft SMTP Server (TLS) id 15.0.698.13; Thu, 30 May 2013 18:54:26 +0000
Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.161]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.8]) with mapi id 15.00.0698.010; Thu, 30 May 2013 18:54:25 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: "Richer, Justin P." <jricher@mitre.org>, Mike Jones <Michael.Jones@microsoft.com>
Thread-Topic: [jose] Should we delete the "typ" header field
Thread-Index: Ac5ct7bsKO37MhFARcu9P04lU2GoQQACcb7gAAE0cIAAACa/UAAg82YAAAcJBvA=
Date: Thu, 30 May 2013 18:54:25 +0000
Message-ID: <49dc8abc726a4acd86283caf833c9751@BY2PR03MB189.namprd03.prod.outlook.com>
References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C5499@TK5EX14MBXC285.redmond.corp.microsoft.com> <030801ce5cc6$5064daf0$f12e90d0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C5787@TK5EX14MBXC285.redmond.corp.microsoft.com> <427D27E7-04B7-43F6-87A1-0ACB20AAFB93@mitre.org>
In-Reply-To: <427D27E7-04B7-43F6-87A1-0ACB20AAFB93@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:2a:2:e8d4:ebf5:24e6:9944]
Content-Type: multipart/alternative; boundary="_000_49dc8abc726a4acd86283caf833c9751BY2PR03MB189namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB190.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(51444003)(24454002)(377454002)(74316001)(47976001)(47736001)(50986001)(74876001)(49866001)(6806003)(81542001)(16601075002)(16676001)(4396001)(76796001)(44976003)(15202345002)(65816001)(76576001)(80022001)(33646001)(54356001)(74662001)(81342001)(63696002)(31966008)(69226001)(76786001)(16236675002)(51856001)(74502001)(71186001)(54316002)(56776001)(74706001)(47446002)(512954002)(74366001)(53806001)(59766001)(20776003)(76482001)(77982001)(79102001)(56816002)(1511001)(46102001)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB021; H:TK5EX14HUBC107.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 08626BE3A5
Cc: Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Should we delete the "typ" header field
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: Thu, 30 May 2013 18:55:52 -0000

I agree that they are fine as-is. We can and should be clearer that these fields don't effect the JOSE processing but are application fields.

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richer, Justin P.
Sent: Thursday, May 30, 2013 8:31 AM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] Should we delete the "typ" header field

I think that the two fields are fine as they're currently defined, as Mike describes below. They're hanging points for information that other applications of the JOSE stack can use to switch functionality out, and as such they should be well-defined and optional to allow general libraries and applications to do their jobs.

 -- Justin


On May 29, 2013, at 7:51 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:


"typ" declares what the type of THIS OBJECT is.
"cty" declares what the type of THE PAYLOAD or THE PLAINTEXT is.

They're different.

In the JWT case, a JWT Claims Set (the normal JWT Payload), which is a JSON Object containing Claims, is a completely different data structure from a JWT, which is a dot-separated list of base64url encoded fields.  The "cty" represents the former; the "typ" represents the latter.

                                                                -- Mike

From: Jim Schaad [mailto:ietf@augustcellars.com<http://augustcellars.com>]
Sent: Wednesday, May 29, 2013 4:43 PM
To: Mike Jones; jose@ietf.org<mailto:jose@ietf.org>
Subject: RE: [jose] Should we delete the "typ" header field

Can you justify why the JWT spec should not specify that  it should not be "ctyp" : "JWT"?

Jim


From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, May 29, 2013 4:24 PM
To: Jim Schaad; jose@ietf.org<mailto:jose@ietf.org>
Subject: RE: [jose] Should we delete the "typ" header field

"typ" is there so that there's a standard header parameter field for declaring what the data structure is so that it's there for applications for which this declaration is useful.  For instance, the JWT spec specifies that "typ": "JWT" can be used to declare that the object is a JSON Web Token, should that be useful in context.

For those of you who may not be aware of it, the JSON Web Signature and Encryption Type Values Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#section-10.2> semantically ties short "typ" names to MIME types - so there's a well-defined way that the types of JOSE objects relate to the well-established MIME type system.  In fact, MIME types are explicitly allowed to be used as "typ" values.

Ironically, there was actually a working discussion on this late 2011 and early 2012 that resulted in the decision to keep "typ" in our specs, rather than having the JWT spec define it, and that resulted in the creation of the registry.  In that thread ("[jose] Comments on the -03 JSON Web Signature document"), you wrote Jim:

[JLS] If it is believe that a parameter this list is going to be "commonly" used by many different profilers, then I believe that the core items needs to be done the in the base specification.  I would therefore not be in favor of punting it out to somebody else.  The only exception would be if we are going to have a very light core and a "real" core specs.  In this case the very light core spec could punt to the "real" core spec.  Having said that I think that a registry would be a good idea.

That's been the state of the "typ" parameter specs ever since - I believe for the good reasons that you cited then.  I haven't heard anyone argue that that reasoning was wrong - only that *their particular use case* may not need a "typ" value.  Just because all use cases don't need it isn't a sufficient argument to delete it and thereby hinder those that do.

                                                                -- Mike

From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, May 29, 2013 3:03 PM
To: jose@ietf.org<mailto:jose@ietf.org>
Subject: [jose] Should we delete the "typ" header field

In reading the documents, I am trying to understand the justification for having the "typ" header parameter in the JOSE documents.

The purpose of the field is to hold the type of the object.  In the past, I believe that values which should now be placed in the cty field (such as "JWT") were placed in this field as well.  However the parameter is optional and an implementation cannot rely on its being present.  This means that for all practical purposes all of the code to determine the value of the type field from the values of the alg and enc fields.  If the field was mandatory then this code would disappear at a fairly small space cost and I can understand why the parameter would be present.

Can anybody justify why this field should be present in the document - or should it just disappear?

Jim

_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose