Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

Mark Mcgloin <> Wed, 29 September 2010 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFC213A6D00; Wed, 29 Sep 2010 08:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fPzGkGeu-rz0; Wed, 29 Sep 2010 08:27:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7D00E3A6B0B; Wed, 29 Sep 2010 08:27:53 -0700 (PDT)
Received: from ( []) by (8.13.1/8.13.1) with ESMTP id o8TFSaK9009038; Wed, 29 Sep 2010 15:28:36 GMT
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id o8TFSaIU3203282; Wed, 29 Sep 2010 16:28:36 +0100
Received: from (loopback []) by ( with ESMTP id o8TFSZG1021876; Wed, 29 Sep 2010 16:28:36 +0100
Received: from ( []) by ( with ESMTP id o8TFSZCR021871; Wed, 29 Sep 2010 16:28:35 +0100
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB941@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <> <90C41DD21FB7C64BB94121FBBC2E72343D460DB941@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-KeepSent: 142A94C3:963BF481-802577AD:0052B3D8; type=4; name=$KeepSent
To: Eran Hammer-Lahav <>
X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009
Message-ID: <>
From: Mark Mcgloin <>
Date: Wed, 29 Sep 2010 16:27:59 +0100
X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 29/09/2010 16:28:02
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Cc: "" <>, "OAuth WG (" <>
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
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: Wed, 29 Sep 2010 15:27:54 -0000

Eran Hammer-Lahav <> wrote on 29/09/2010 15:50:33:

> >
> > -1 to splitting acquiring and using a token. It may not confuse
> people actively
> > engaged in the WG but what about everyone else?
> We are already splitting it, by putting signatures elsewhere. Just
> because you might think bearer tokens are the 'obvious choice' and
> signatures are the 'optional more advance choice', you are still
> splitting the protocol over multiple parts. It is just that your
> preferred way of splitting it is optimized to what you care most
> about. I have made the same argument about the readability of the
> specification without signatures in core and was shut down because
> it will delay the work too much and other reasons.

Yes I know and I realise there are conflicting opinions and you want a
compromise. I do not want to block that, hence my mild -1, but want to
raise these 2 points now before the split in case others feel they are
important points.

> > Also, as Torsten and I look at security considerations, I wonder
> if there are
> > some examples that link the threat model for acquiring a token and
using a
> > token.
> This is possible, but there is absolutely no benefit from the way
> the draft is structured today. If you strive to offer a complete and
> comprehensive solution and security review, you clearly have to
> include signatures in the same document. How would you discuss these
> examples and dependencies without the full picture? IOW, how is
> including bearer token but not other alternatives make answering
> these questions in the core specification any easier? Why is it any
> less useful to discuss these questions in each of the token
> authentication schemes? After all, it is the nature of the scheme
> that dictates everything else.
> This argument is valid but has nothing to do with moving section 5 out.

I think acquiring and using a token can be considered core as you always
need both. I don't have valid security consideration linkage between
acquiring and using the token to back up my assertion that it may confuse
developers if we separate them (yet)

> This leaves readability as the only potential argument against
> splitting. Why not try it out? What's the worse that will happen? We
> have to put it back in and look for a different compromise?
> And last, if you are going to opposed this proposal, then the burden
> is on you to offer an alternative that is going to address the
> concerns and parameters presented in my original post. By
> definition, a compromise means you don't get everything you want, so
> what are you willing to give up to help resolve these otherwise
> blocking issues? I am not trying to tease anyone, but asking an
> sincere question. Every other proposal has been rejected with
> sufficient resistance to suggest it will not last through the
> multiple review stages.

I am fine with breaking the spec if it means progress towards review stages