IETF Logo Mail Archive

[OAUTH-WG] SAML Bearer Spec 09 - Refresh Clarification

Phil Hunt <phil.hunt@oracle.com> Fri, 04 November 2011 20:41 UTC

Return-Path: <phil.hunt@oracle.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 7545211E808E for <oauth@ietfa.amsl.com>; Fri, 4 Nov 2011 13:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 ztSH8+VpRLp3 for <oauth@ietfa.amsl.com>; Fri, 4 Nov 2011 13:41:09 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92211E8082 for <oauth@ietf.org>; Fri, 4 Nov 2011 13:41:09 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA4Kf7Ro006914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Fri, 4 Nov 2011 20:41:08 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pA4Kf5v8002942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Fri, 4 Nov 2011 20:41:07 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pA4Kf0l0009506 for <oauth@ietf.org>; Fri, 4 Nov 2011 15:41:00 -0500
Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Nov 2011 13:41:00 -0700
From: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_183460ED-B23E-47BF-9350-13F2BAF6F023"
Date: Fri, 04 Nov 2011 13:40:58 -0700
Message-Id: <918554FB-F7B1-42E7-AA49-E3611F435796@oracle.com>
To: "oauth (oauth@ietf.org)" <oauth@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4EB44DE4.018E,ss=1,re=0.000,fgs=0
Subject: [OAUTH-WG] SAML Bearer Spec 09 - Refresh Clarification
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: Fri, 04 Nov 2011 20:41:10 -0000

Section 4.5 of the OAuth Core spec provides that extension spec MAY issue refresh tokens.  Yet, section 3.1 of the OAuth2 SAML Bearer specification currently says SHOULD NOT (from draft 09):

> Authorization servers SHOULD issue access tokens with a limited lifetime and require clients to refresh them by requesting a new access token using the same assertion, if it is still valid, or with a new assertion.  The authorization server SHOULD NOT issue a refresh token.

There has been some confusion as to why authorization servers SHOULD NOT issue refresh tokens. Apparently this wording was put in place because a SAML Bearer authorization might have a shorter life than typical refresh token lifetime. Hence there was a concern that an authorization server would inadvertently issue a long-lasting refresh token that outlives the original SAML Bearer authorization.  In order to make this concern clear I propose the following text that makes clear the concern and makes refresh tokens more permissive:

Authorization servers SHOULD issue access tokens with a limited lifetime and require clients to refresh them by requesting a new access token using the same assertion, if it is still valid, or with a new assertion.  The authorization server SHOULD NOT issue a refresh token that has an expiry longer than the lifetime of the authorization grant.

I'm not aware of any other concerns regarding refresh tokens being issued in conjunction with SAML Bearer assertions?  Are there any concerns that suggest we should keep the wording as generally SHOULD NOT?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

v2.23.0 | Report a Bug | By Email