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:

> 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
> >
>