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.h...@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.h...@oracle.com > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
