add a method for the resource server to constrain the validity period of access tokens

[zenomt]

in the current POP token scheme, the client manufactures an access token to present to a server. the client chooses how long this token is valid for (nbf and exp), constrained only by the validity of the id_token obtained from the client's OpenID Provider.

this is problematic for at least three reasons:

1. there's no reasonable way for the server to indicate to the client that validity period is longer than the server would prefer for security reasons
2. should the server decide to revoke or otherwise not honor an access token, it might need to remember something about the token (for example, the entire token, or a hash of it, or its confirmation key, or the id_token or hash of it, or the webid) for at least as long as the validity period of the token, which could be longer than the server is prepared to remember it.
3. there is no opportunity for the resource server to issue a token valid for longer than what the client determined. this might be useful in situations where the server is heavily loaded and wants to put off expensive (re)verification of the identity associated with the token, which can involve additional cryptographic operations and network accesses.

possible ways of addressing this include (but are not limited to):

1. implement Consider adding a 'nonce' param to WWW-Authenticate response header #3 and include with the challenge an expires_in or similar (doesn't handle case 3 above though), and rejecting any token that includes the challenge and that has an exp after challenge's expiration date.
2. obtain an access token from an authorization server instead of making one in the client, where the resource server determines the validity period of its access tokens directly, and communicates that to the client.

[acoburn]

This issue has gone stale and is, apparently, no longer relevant.