Re: [OAUTH-WG] Section 10.3 client advice inapplicable?

John Bradley <ve7jtb@ve7jtb.com> Sun, 19 February 2012 15:31 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1333E21F8549 for <oauth@ietfa.amsl.com>; Sun, 19 Feb 2012 07:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level:
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 l7DJkExJhqge for <oauth@ietfa.amsl.com>; Sun, 19 Feb 2012 07:31:48 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCF621F8545 for <oauth@ietf.org>; Sun, 19 Feb 2012 07:31:48 -0800 (PST)
Received: by yenm3 with SMTP id m3so2698378yen.31 for <oauth@ietf.org>; Sun, 19 Feb 2012 07:31:47 -0800 (PST)
Received-SPF: pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.79.138 as permitted sender) client-ip=10.236.79.138;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of ve7jtb@ve7jtb.com designates 10.236.79.138 as permitted sender) smtp.mail=ve7jtb@ve7jtb.com
Received: from mr.google.com ([10.236.79.138]) by 10.236.79.138 with SMTP id i10mr17395891yhe.12.1329665507768 (num_hops = 1); Sun, 19 Feb 2012 07:31:47 -0800 (PST)
Received: by 10.236.79.138 with SMTP id i10mr13360825yhe.12.1329665507690; Sun, 19 Feb 2012 07:31:47 -0800 (PST)
Received: from [192.168.1.213] (186-107-131-167.baf.movistar.cl. [186.107.131.167]) by mx.google.com with ESMTPS id a24sm15038605ana.10.2012.02.19.07.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Feb 2012 07:31:46 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_3035A7A6-6D7F-4C7B-B4CF-12BB252492F0"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAE358b7joJKo5aK9PHmno_8Y6myQjjbafSRY_+wQyJH2P14NoA@mail.gmail.com>
Date: Sun, 19 Feb 2012 12:31:42 -0300
Message-Id: <61C6C5B6-A678-41A6-BC5B-4FE81D4E266C@ve7jtb.com>
References: <CAE358b7joJKo5aK9PHmno_8Y6myQjjbafSRY_+wQyJH2P14NoA@mail.gmail.com>
To: Andrew Arnott <andrewarnott@gmail.com>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmwsFIQvB12N7OhGzR6yrpOjGFTlMDS6QrwrlDpn4+jCWQroJTBLC3nPtsxujEeP7CeE3oU
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Section 10.3 client advice inapplicable?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 19 Feb 2012 15:31:49 -0000

There is nothing explicit in draft 23 about requesting a scope lifetime.   It is as they say fuzzy.

You know that some people have used additional scopes like offline_access to request longer lifetimes.

It may be reasonable to preconfigure something at the tAuthorization server based on client_id,  but there is also the question of how to present the options to the user in an understandable way.

Fortunately or unfortunately this has been punted to the specs using OAuth to define.    

How to deal with this question for openID Connect is on the agenda for our F2F in San Francisco on Mar 2.

John B. 
On 2012-02-19, at 12:08 PM, Andrew Arnott wrote:

> From draft 23, section 10.3:
> The client SHOULD request access tokens with the minimal scope and lifetime necessary. The authorization server SHOULD take the client identity into account when choosing how to honor the requested scope and lifetime, and MAY issue an access token with a less rights than requested.
> 
> 
> I can't find the part in the spec where the client can request access tokens in such a way as to influence the lifetime.  Why is the client then being advised in the above section to minimize the lifetime of the access tokens it asks for?
> 
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth