No means no! (Alice's right to revoke)

[mrpotes]

Section 3.6 states that:

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.

However, consider the following scenario:

• Alice shares her health record with all doctors at the practice
• Evil Dr Bob acquires an RPT and refresh token
• Alice discovers that Dr Bob is selling her health record online, so creates a deny policy for Dr Bob (or maybe she just switches practices and revokes existing policy)
• Dr Bob continues to sell her health record online for the duration of the refresh token's lifetime, because the AS "MUST NOT" perform authorization assessment on RPT refresh.

This seems contrary to HIPA and GDPR (and others), which (as I understand it, IANAL) guarantee a right to revoke and require a best effort on the part of the AS to enforce that revocation.

[jricher]

For this, Alice can revoke all of Dr. Bob's tokens, including the refresh token.

The language in question was put in there to keep people from tying all the original claims to the refresh token and re-running the engine on it. The refresh token should be there to refresh a valid existing authorization -- if that authorization isn't valid anymore, the refresh token shouldn't be valid either.

[mrpotes]

Interesting, so on any policy change the AS needs to re-evaluate all tokens that have been issued for that resource?

If so, should this be mentioned?

On 28 Jul 2017 6:20 pm, "Justin Richer" notifications@github.com wrote:

For this, Alice can revoke all of Dr. Bob's tokens, including the refresh token.

The language in question was put in there to keep people from tying all the original claims to the refresh token and re-running the engine on it. The refresh token should be there to refresh a valid existing authorization -- if that authorization isn't valid anymore, the refresh token shouldn't be valid either.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/348#issuecomment-318712819, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6kNnrhIye-tNnIGem6IHc9-_EcHKK7ks5sShhkgaJpZM4OmtPY .

[jricher]

It could do that, but I think you'd be hard pressed to say that's "should" -- after all, the tokens were valid when they were issued. And what does it mean for a token to be reevaluated, anyway? Does that mean the server has to store all of the original claims that were used to issue the token? That's a huge privacy risk (which is pointed out in the considerations section regarding the PCT, and is mitigated by its use). Plus some of those claims might be expired anyway, so what's an AS to do in that case?

If you wanted to implement a cascade, you could instead tie to the policy that was fulfilled to issue a token, by internal reference, and cascade a delete on downstream tokens on every edit. That's a bit extreme, but it's cautious.

I think instead the AS needs to let Alice say things like "revoke tokens issued to this client" or "revoke tokens on this resource", for instance. But that's just internal token management and UI, not really anything for our spec to say something about. If the AS wants to get fancy and figure out that a client was Dr Bob's client (a tricky thing to do in a cross-domain world), then it could expose that label to Alice, too. But this isn't about changing Alice's policy, it's about Alice making a decision about what has access right this second.

I believe the text as written is fine in this regard.

[xmlgrrl]

Right, there are TTL strategy and UX implications here. Alice certainly doesn't think in terms of tokens. She thinks -- if anything -- possibly in terms of policy or sharing/unsharing or something. If she wants to "stop sharing" something with somebody, it behooves the AS to do what it can in preparation for resource requests coming from them. So it sounds like there are a) some implications for AS sophistication here, and b) maybe some implications for those profiling UMA who want to get specific about how deep the rabbit hole goes. (Disconnected and stateless deployment use cases?)

[xmlgrrl]

Eve and James discussion:

• The entire point of the refresh flow is a 100% back-channel mechanism for access token acquisition.
• RPTs are fine-grained (specifically, on individual permissions) while refresh tokens are coarse-grained (meaning, they apply to a whole RPT).
• The RPT wrapper's value all on its own is to ensure the permissions within are protected. A short RPT lifetime doesn't prevent long permission lifetimes. If the RPT is an opaque handle, you want to ensure that string doesn't "get out", so refreshing is valuable.
• Refresh flow means that the RqP can't be present to update any claims that the AS is holding persistently for the (potential) purpose of re-evaluating policy.
• The OAuth refresh flow doesn't include the option of a PCT (an UMA construct) on the refresh.
• Policies can be arbitrarily complex and can change between initial RPT issuance and refresh request in arbitrarily subtle ways, e.g., removal of a scope, introduction of a new "deny"-style policy.
• The spec text doesn't seem to actually prohibit re-evaulation ("MUST NOT treat...", not "MUST NOT re-evaluate..."), or at least as much as we thought. This needs clarification at the least.
• Some relevant regulations (HIPAA) have a notion of enabling whatever constitutes a best effort to find/execute the policy (e.g., in consenting to share some medical data but later changing your mind).
• "Always re-evaluating" as a choice (because of the arbitrary/subtle stuff above) and "never re-evaluating" as a choice (because of refreshing a pointless RPT) both have their downsides.

Eve is starting to come down on the side of:

• Allowing the AS to re-evaluate on refresh (clarifying the existing wording a lot more)
• Acknowledging -- in a security consideration? -- that if re-evaluation takes place, it may not have all necessary information (that is, new claims from the requesting side cannot be provided, nor can a PCT that correlates to persistently held claims)
• Recommending that the AS inform the RO, e.g. through documentation, of its re-evaluation practices when of necessity it must be incomplete

We also discussed the notion of letting the client add an optional PCT to its refresh request, which still would count as "back-channel". See 6749 Sec 6. We'd also have to include our definition of this/how to use it in our IANA registration request for OAuth parameters. Actually, let's say the client has an expired RPT and tries a refresh. If it fails, the client could just turn around and approach the token endpoint as normal, with a PCT; that's a kind of "back-channel refreshing flow with PCT" without having to change/add anything here.

Do we need to clarify this point? If the refresh is not possible but the client has an expired RPT (particularly in cases where the permissions last longer than the RPT itself), it should still be able to submit that RPT for an upgrade. So maybe #349 isn't actually an error at all, as long as the RPT belongs to this client etc.

Maybe we could see the refresh flow as the version of refresh that definitely doesn't involve re-evaluation and thus could only ever refresh the RPT's active status and token-level parameters, and the RPT upgrade flow (with PCT as necessary) as the version of "refresh" (really on a refresh-upgrade continuum involving the RPT contents) that definitely does involve re-evaluation.

In an enterprise WAM setting, you might have agents that cache policy and detect when a resource has been affected by a policy change. Here, a) the "user" (RqP) isn't there, and b) we've got an OAuth-based architecture: it's about tokens and entitlements (permissions/scopes) within them as an indirection layer between policy and access requests.

Eve will send an email to the WG list outlining the options we can think of.

[xmlgrrl]

Per UMA telecon 2017-08-23 (see complete notes there; these decisions relate to #349 too):

• Clarify the current wording to explicitly prohibit the AS from re-evaluating policy: "The authorization server MUST NOT perform an authorization assessment calculation on receiving the client's request to refresh an RPT."
• We want to move 99% of FedAuthz Sec 1.4.1 to Grant Privacy Considerations (except for the PAT part). The PAT part should remain in FedAuthz, and it should be part of the Privacy Considerations.
• Currently it says "Supplying an existing RPT gives the authorization server the option of upgrading that RPT instead of issuing a new one (see Section 3.3.5.1 for more about this option)." We should add "Supplying an existing RPT (which MAY be expired) ..." This is sufficient for indicating that this isn't an error condition.
• Create a new issue for James's idea of making the permission ticket optional when upgrading the RPT, and put the "extension" label on it.

(Regarding the last bullet: In other words, this is not a V2.0 issue.)