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 <bcampb...@pingidentity.com>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.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
