IETF Logo Mail Archive

Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

Brian Eaton <beaton@google.com> Tue, 15 June 2010 04:02 UTC

Return-Path: <beaton@google.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 7F49F3A6A1D for <oauth@core3.amsl.com>; Mon, 14 Jun 2010 21:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 L3XiKvWTbZYH for <oauth@core3.amsl.com>; Mon, 14 Jun 2010 21:02:09 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8A7833A6813 for <oauth@ietf.org>; Mon, 14 Jun 2010 21:02:09 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o5F429w5017663 for <oauth@ietf.org>; Mon, 14 Jun 2010 21:02:10 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276574530; bh=ZLZ757EBjLRREPItQS1ZiaLDAzA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=HbhOKCMyDfgDrjdx7vlqyqYiCWzegLSRBQ+ly6YqhCVUdcU1TX3KT/UUfX/NO8dPH Gs10XP89wGAaMXf1nLhiA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=f/a6U5daDC1v3XujsxIdtz5aLM1eA/coVkpt4L5pZd/L9dkS8K1BDr4cvQm8zeQDX uDp5B3DJeg89IC3TcN6Mg==
Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by wpaz5.hot.corp.google.com with ESMTP id o5F427tk021690 for <oauth@ietf.org>; Mon, 14 Jun 2010 21:02:08 -0700
Received: by pvc22 with SMTP id 22so1382778pvc.1 for <oauth@ietf.org>; Mon, 14 Jun 2010 21:02:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.60.21 with SMTP id i21mr4638813wfa.149.1276574527352; Mon, 14 Jun 2010 21:02:07 -0700 (PDT)
Received: by 10.142.207.21 with HTTP; Mon, 14 Jun 2010 21:02:07 -0700 (PDT)
In-Reply-To: <AANLkTil1viRqVgwJzmq7N1W21TPeT5RuclBF5DmPvVVM@mail.gmail.com>
References: <AANLkTil1viRqVgwJzmq7N1W21TPeT5RuclBF5DmPvVVM@mail.gmail.com>
Date: Mon, 14 Jun 2010 21:02:07 -0700
Message-ID: <AANLkTimkNRuv_iiVFupLf4YQ0aYOEH3giuyzD7DM3ip-@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Andrew Arnott <andrewarnott@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response
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: Tue, 15 Jun 2010 04:02:10 -0000

On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> For an application I'm building, the installed client app will have
> intermittent windows of time where it can obtain a (non-OAuth) assertion for
> user identity.  During this time, it seems appropriate for it to use the
> assertion flow to obtain an OAuth authorization so that it can impersonate
> the user.  So far this is just standard Assertion Flow stuff.  But without a
> refresh_token, the app will break when the access token expires if the app
> doesn't have the ability at the moment (due to not being on the corporate
> network at the moment for example) to obtain a new assertion.  Since the
> security model for this app would certainly allow for a refresh_token to be
> issued from the original OAuth authorization server exchange, this would
> solve it, if the spec didn't specifically ban such a parameter.

I think this is a different use case than the one envisioned by most
people who are using the assertion flow.

I'm inclined to steer different use cases to different profiles.  It
makes it much easier to guide deployments, for example.

Cheers,
Brian

v2.46.0 | Report a Bug | By Email | System Status