Validity of an access token

[Denisthemalice]

In section 1.4, the text states:

(8) The client instance calls the RS (Section 7.2) using the access token until the RS or client instance determine that the token is no longer valid.

(9) When the token no longer works, the client instance fetches an updated access token (Section 6.1) based on the rights granted in (5).

It is up to the RS to know when or whether a new access token is necessary. For instance, it is sufficient to present only once an access token that indicates that the end-user is graduated from some school. In such case, if the RS can memorize this attribute and it is no more necessary to present the same access token again either within this session or for another session.

"exp" as currently defined in RFC 7519 means:

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.
From a client point of view, if the access token is not opaque, it is able to know until when an access token can be presented to a RS.

From a RS point of view it only means that the access token cannot be accepted after that time, but this does not mean that an already accepted token is considered as invalid once it has been accepted . The decision is up to the RS (or its RO).

Section 1.4.5. about "Refreshing an Expired Access Token" would need to be revisited.

[fimbault]

A few remarks :

• currently the default assumption is that the access token is opaque (although I would personally favor at least knowing the format used, cf Token format #189)
• I understand your point in theory but for an RS implementer, it's usually easier to just take the exp as well (as a common reference with the client, directly embedded into the token), and it's not that much of an issue if you get a short duration and and an associated rotation mechanism. I'm not sure we would gain a lot from having an additional dependency on the RS for his own internal expiry.

[Denisthemalice]

The main point is that it is up to the local policy of the RS to determine how long an attribute remains valid.

Let us take two examples:

• If the attribute is a graduation from a University, it may be assumed that it remains valid at least during one year.
• If the attribute is a home address, it may be assumed that it remains valid at least during three months,

When the RS determines that the attribute is no more valid, then there will be an error 403 and the RS will indicate to the client what is required. See the issue #203.

It is then questionable whether "Refreshing an Expired Access Token" is really needed. Asking for a new access token may be simpler.

[fimbault]

Well, viewed as such, it could be a simplifying assumption (refresh tokens are kind of an issue in themselves). But what should the client do if the RS doesn't have such a policy or when it seems unreasonnable?

[Denisthemalice]

It is always up to the RO of the RS to determine how long an attribute can remain valid without the need to send a new access token.

If/when the RS returns an error 403 to the client, it is up to the client to determine what is simpler: get a new access token or refresh an access token.

[fimbault]

In our current architecture, we don't have a RO at the RS (of course it's still possible for him to have an account there, but we're agnostic). So the only assumption is that the RO will be reachable as part of the grant negociation process.

If we need to plan for a refresh token anyway, it's easier to keep expiration policies common to all parties.

[jricher]

Tokens may or may not have time-based expirations at all, GNAP is agnostic to this. This level of behavior specification is not required for interoperability as defined by GNAP. Methods for validating access tokens are discussed in GNAP-RS created by #246

[Denisthemalice]

@jricher: It seems that we are in agreement.

Some text should be added into the current draft to capture this agreement.

However, this is not currently captured in #246 since the single occurrence of "valid" in issue #246 is a reference to this issue #191.