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

Eran Hammer-Lahav <> Mon, 27 September 2010 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BE843A6DA9 for <>; Mon, 27 Sep 2010 10:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eIKcjb8EH4TV for <>; Mon, 27 Sep 2010 10:00:08 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 0A24C3A6B96 for <>; Mon, 27 Sep 2010 10:00:07 -0700 (PDT)
Received: (qmail 2505 invoked from network); 27 Sep 2010 17:00:45 -0000
Received: from unknown (HELO ( by with SMTP; 27 Sep 2010 17:00:45 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([]) with mapi; Mon, 27 Sep 2010 10:00:36 -0700
From: Eran Hammer-Lahav <>
To: Phil Hunt <>, "Tschofenig, Hannes (NSN - FI/Espoo)" <>
Date: Mon, 27 Sep 2010 10:00:40 -0700
Thread-Topic: [OAUTH-WG] Document Management Issue (Signatures)
Thread-Index: ActeZG1WR1nCRk7wQjiRzmYbxaOXzwAAIRhA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D460DB374@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343D460DB374P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [OAUTH-WG] Document Management Issue (Signatures)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Sep 2010 17:00:14 -0000

I would also be happy with the core only dealing with *getting* a token, and moving all text about *using* a token to other documents. This will produce three parts:

1.       Getting a document

2.       Using bearer tokens

3.       Using cryptographic tokens

Part 3 can include both the JSON token and a 1.0a HMAC-SHA-1 solution (unless we can solve that disagreement which I highly doubt). Or part 3 can be just the signature framework. With such a setup, I'm happy to close part 1 and 2 immediately and move them along (only hold final RFC publication until part 3 is ready).


From: [] On Behalf Of Phil Hunt
Sent: Monday, September 27, 2010 9:52 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Re: [OAUTH-WG] Document Management Issue (Signatures)

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.


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)

OAuth mailing list<>