James and I met this morning to analyze this issue a lot more closely; please see the thread for detail.

In short, we noticed a) lack of wording clarity (is the AS actually prohibited from re-evaluating?), b) the fact that RPT upgrading is a kind of refreshing of the RPT envelope but with definitive re-evaluation (and the option of providing a PCT as input), c) a plethora of circumstances where re-evaluation on refresh might be valuable but also incomplete, and d) the distinction between token-level lifetimes (good to keep short) and permission-level lifetimes (could be long).

I said I would send a note suggesting options to consider, so here they are:

• No change to the current wording in Grant Sec 3.6: "The authorization server MUST NOT treat the client's request to refresh an RPT as if it were a request for a new RPT requiring an authorization assessment calculation."
• Clarify the current wording to explicitly prohibit the AS from re-evaluating policy (currently we're not sure it achieves that).
• Change the current wording to allow the AS to choose whether to re-evaluate policy (acknowledging that it may have incomplete inputs with which to do so).
• Change the current wording to require the AS to re-evaluate policy (acknowledging that it may have incomplete inputs with which to do so).
• ...Sub-option on all: Add more explanation and and possibly security considerations text.