Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgraded RPT logic vs. our old "discard" language #281

Closed
xmlgrrl opened this issue Feb 20, 2017 · 2 comments

Comments

Projects
None yet
1 participant
@xmlgrrl
Copy link

commented Feb 20, 2017

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 xmlgrrl added core V2.0 labels Feb 20, 2017

@xmlgrrl

This comment has been minimized.

Copy link
Author

commented Feb 21, 2017

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 added a commit that referenced this issue Feb 23, 2017

@xmlgrrl

This comment has been minimized.

Copy link
Author

commented Feb 23, 2017

Closed in Core 2.0 rev 16.

@xmlgrrl xmlgrrl closed this Feb 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.