Re: [OAUTH-WG] Document Management Issue (Signatures)

Phil Hunt <phil.hunt@oracle.com> Mon, 27 September 2010 16:51 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02C73A6B6F for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 09:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKKYqw0gnryP for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 09:51:49 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1C1123A6D90 for <oauth@ietf.org>; Mon, 27 Sep 2010 09:51:48 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8RGqQc5013918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Sep 2010 16:52:27 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8R1Qc1q024950; Mon, 27 Sep 2010 16:52:25 GMT
Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 640393351285606326; Mon, 27 Sep 2010 09:52:06 -0700
Received: from [192.168.1.2] (/24.87.207.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 Sep 2010 09:52:03 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-13-208957936"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45031BA596@FIESEXC015.nsn-intra.net>
Date: Mon, 27 Sep 2010 09:51:59 -0700
Message-Id: <DB4FC8C2-816C-4527-8EC4-BC22B171B34C@oracle.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45031BA596@FIESEXC015.nsn-intra.net>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
X-Mailer: Apple Mail (2.1081)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Document Management Issue (Signatures)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Sep 2010 16:51:51 -0000

I think it would also help with handling revisions over time. Changes to signature specifications, etc over time, won't impact the core specification -- keeping it stable and well understood.

Maybe a compromise is to include the 1.0a stuff in the core spec as "legacy" (since it was in the 1.0 core), but reference a normative external signature extension specification document for 2.0 on.

Phil
phil.hunt@oracle.com




On 2010-09-27, at 9:43 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Hi all
> 
> I wonder whether the question of "signature in the main specification or in a separate document" does not really matter. It is purely a matter of document management style.
> 
> The important question is whether there will be a **mandatory to implement** or **mandatory to use** someone in the document set. Mandatory to use is typically hard to enforce unless there is only one approach possible. This does not seem to be the case.
> 
> So, everything then boils down to the question: What is mandatory to implement? (in this specific case with regard to security)
> 
> Ciao
> Hannes
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth