>  >  Hey Allen,

>  >  So a dumb question... why can't the session scope be handled with a
>  >  normal Access Token?

>  >  1. Get Access Token scoped to a short session via normal mechanism (say
>  >  it expires in 30 minutes)
>  >  2. When AT expires, you get a 401 Unauthorized with a WWW-Authenticate
>  >  and additional info indicating that it's just a session timeout
>  >  (xoauth_session_timeout, say).
>  >  3. You then re-authenticate; I'd suggest that this be the same as a
>  >  first-time authentication, but you pass in the expired Access Token
>  >  instead of the Request Token.  This lets you do the DB lookup required
>  >  to verify that the user's consent still stands, they haven't changd
>  >  their password, etc. but also lets you mint a new 30-minute Access Token
>  >  and return it to the client.
>  >  4. Lather, rinse, repeat.

>  >  Of course, you control the Access Token in this case and you encrypt
>  >  enough information in it to be able to verify access for up to 30
>  >  minutes without an expensive DB call.

>  >  I think this would be less new spec work and code than a new Session
>  >  Token; all you need is a way to know that you've got a session-scoped
>  >  Access Token, a way to know when it expires, and a way to exchange it
>  >  for a newly minted one.

>  You don't really need to know about expiration as a property of the
>  token.  The provider will tell you it's expired.  So why not just pass
>  the AT back to the AT endpoint, rather than treat it at an RT?  Then
>  the provider can choose to exchange it for a new one.

>  .. Adam