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

Brian Campbell <bcampbell@pingidentity.com> Mon, 23 January 2012 20:23 UTC

Return-Path: <bcampbell@pingidentity.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 7817421F8729 for <oauth@ietfa.amsl.com>; Mon, 23 Jan 2012 12:23:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.143
X-Spam-Level:
X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 O7mVZcls-b0F for <oauth@ietfa.amsl.com>; Mon, 23 Jan 2012 12:23:17 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id EA42421F8721 for <oauth@ietf.org>; Mon, 23 Jan 2012 12:23:16 -0800 (PST)
Received: from mail-vw0-f45.google.com ([209.85.212.45]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTx3BtL9Z0kDJ1+VEGxFshBFCgEqoYs23@postini.com; Mon, 23 Jan 2012 12:23:17 PST
Received: by mail-vw0-f45.google.com with SMTP id k17so2454015vbj.32 for <oauth@ietf.org>; Mon, 23 Jan 2012 12:23:16 -0800 (PST)
Received: by 10.52.174.47 with SMTP id bp15mr1648150vdc.124.1327350195149; Mon, 23 Jan 2012 12:23:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.111.197 with HTTP; Mon, 23 Jan 2012 12:22:44 -0800 (PST)
In-Reply-To: <CA+k3eCTYUQuYE1ZU3_yPWkXmXOjtS2H-OEdezpdoPwcBPqZKaQ@mail.gmail.com>
References: <918554FB-F7B1-42E7-AA49-E3611F435796@oracle.com> <CA+k3eCTYUQuYE1ZU3_yPWkXmXOjtS2H-OEdezpdoPwcBPqZKaQ@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 23 Jan 2012 13:22:44 -0700
Message-ID: <CA+k3eCT_k9n8Rw_CX2WYtXBLhaJ3U6QJnr8vokgHKRpq1PquKg@mail.gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Gm-Message-State: ALoCoQnA2aFtUNiOX3R8oheO0df5OqMiJ1EIlxu97mfahdCYumjI2eZ1QHxv2sGYkgP+NZvi3Aqe
Content-Type: multipart/alternative; boundary=bcaec51b17bbdfda6d04b737cc3e
Cc: "oauth \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [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: Mon, 23 Jan 2012 20:23:18 -0000

Sorry, I had a section reference and link wrong in the previous message.
The question/suggestion about moving some text into the "OAuth 2.0
Assertion Profile" should have referenced section 4.2 and linked to here:
http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2

That mistake also gives me an excuse to raise this to the WG again.  I
suggest that whatever text we settle on be moved to general assertion
profile. I'm not sure I know what that text should be.

On Fri, Dec 16, 2011 at 3:58 PM, Brian Campbell
<bcampbell@pingidentity.com>wrote;wrote:

> Hey Phil,
>
> Your understanding is pretty much inline with how I understand it.
> That text actually originates from earlier versions of the core spec
> (I think -09 [1] was the last sighting). And I carried it over when
> the grant_type got generalized and the assertion pieces moved into the
> SAML/OAuth draft.
>
> The main idea was that the extension grants (or at least assertions)
> relied on some existing trust framework and that issuing a refresh
> token would effectually undermine that by giving the client a new way
> of getting access outside the established framework of trust. So, for
> example, with an RT a fired employee might still be able to access
> resources at a SaaS provider.
>
> That was the thinking anyway but I don't disagree that the wording in
> the draft could make that more clear and/or be a less restrictive.
>
> Regarding the text you've proposed, I'm not sure I know exactly what
> "lifetime of the authorization grant" means or how the AS would know.
> And I think it might be too ambiguous to have as normative language.
> Can you give a workable definition? Or was it intentionally left kind
> of vague?
>
> I'll should also note that that exact same text is in section 3.1 of
> the "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0" [2]
> draft.  Whatever we decide, I can't think of any reason it would't
> apply to both drafts. And that suggests that it should be moved up
> into the "OAuth 2.0 Assertion Profile" - perhaps into section 4.1.3
> [3]?
>
> Thanks,
> Brian
>
> P.S. My apologies for the extremely slow response - this one just
> slipped though the cracks for a while - I have no other excuse.
>
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3
> [2] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03#section-3.1
> [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.3
>
>
>
> On Fri, Nov 4, 2011 at 2:40 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> > 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
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>