Upgraded RPT logic vs. our old "discard" language

[xmlgrrl]

Now that we decided firmly that a client includes an RPT on its request in order to get upgraded, and an AS signals whether an upgrade happened through a flag on the response, is this language correct anymore?

"If the client included an existing RPT in its request and the authorization server issues a new RPT, the authorization server SHOULD revoke the existing RPT, if possible, and the client MUST discard its previous RPT."

Shouldn't the client keep its existing RPT if it didn't get upgraded? What should we say instead?

I've kept this in what will likely be UMA Core 2.0 rev 15 Sec 3.6.6 for now, but I don't think it's right...

[xmlgrrl]

In ad hoc telecon 2017-02-21, we discussed the difference between "upgrading" permissions and a same-string RPT vs. a new-string RPT. This paragraph is meant to apply to the latter paradigm. OAuth allows an AS to issue a new refresh token, and you're supposed to get rid of your old refresh token; we copied their wording for RPTs here. If the upgraded flag comes back false, that's the only complicated case. From the client implementation perspective, they should just keep whatever the AS hands back. If they have a PCT (RqP state), they don't lose too much except a redirect trip to the AS.

So should we clarify by adding "string to "RPT" or something, and not say "existing RPT" for the request?

request=ABC response=XYZ (upgraded with ABC) --> AS revoke ABC and client discard ABC

"If the authorization server is upgrading an RPT, and the RPT string is new rather than repeating the RPT provided by the client in the request, then the authorization server SHOULD revoke the existing RPT, if possible, and the client MUST discard its previous RPT."

Are there any similar instructions in the case where the AS declines to upgrade the RPT in the client's request and issues an RPT anyway?

request=ABC response=XYZ (not upgraded) --> we said we're staying out of "the AS MAY choose to upgrade" logic

So the client gets to hold on to its RPT, and the AS gets to do whatever it wants. So add any MAYs?

"... If the authorization server does not upgrade the RPT but issues a new RPT, the client MAY retain the existing RPT."

Put the new wording blocks after the parameter definitions.

[xmlgrrl]

Closed in Core 2.0 rev 16.