Humongously useful, thank you! Comments on three parts:

====

Policy conditions are out of scope for UMA, so the AS could be configured with all kinds of stuff that is out of scope for what UMA cares about, but since "the AS only knows what the RS told it" as far as UMA goes, RSReg definitely counts as a reasonable limiting factor in my book.

====

Regarding the question of whether the AS honors previous RPTs (K, L): I suspect this is a bit more complex, partially because any RPT could cover more than one resource already, so L is a possibility at any time. The "previous RPT" case would happen when the client chooses to bring a failed RPT to the token endpoint and asks for an RPT that won't fail. The AS has a choice too (as I put it in a recent message):
  1. (Client can bring no RPT and ask for one -- not a concern)
    1. (AS can issue a new RPT A -- not a concern)
  2. Client can bring RPT A that doesn't have a permission for what it wants to do and ask for an RPT that works for what it wants to do
    1. AS is allowed to reissue the existing RPT A (same RPT string), having added the relevant permissions to it
    2. AS can issue a new RPT B (different RPT string), having added the relevant permissions to it
      1. AS can invalidate the old RPT A that the client brought it upon this action
      2. AS can retain the validity of the old RPT A that the client brought it and any of its permission(s) -- presumably ones that are still good and that the client didn't just try to exercise but found wanting
(Justin, you suggested that if the AS issues a new token, we say "the AS SHOULD revoke the existing RPT, if possible" and "the client MUST discard its previous RPT" on the reasoning that this matches OAuth refresh token guidance, which I like.)

You can see I was presuming that reissuing an existing RPT would upgrade that token. If it contained totally orthogonal resources and scopes relative to the current request, it could still be upgraded with a relevant resource and scope.

Is it also possible that the AS's TTL strategy and/or the RO's other changes in policy might also dictate "cleaning house", so to speak, and downgrading other permissions while it's upgrading the permission of interest? Or is this not fair game?

====

Regarding the pièce de résistance (French, meaning "piece of resistance"), the pseudocode, it seems to be pretty complete and logical, and I like that it preserves George's rationale of client registration as a round-trip-saving exercise. The only thing I can't find in it (and this whole discussion, really) is some statement of how scopes match to resources, given that identical scopes may appear on multiple resources. I'm hoping that doesn't have to have to be so much a complication as a matching strategy.



Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Fri, Jan 6, 2017 at 2:56 PM, Justin Richer <jricher@mit.edu> wrote:
I’ve been working on the set math problem and I’ve been trying to lay out scenarios using this spreadsheet to help me sort my thoughts:


I’ve left a bit of space in the spreadsheet for additional combinations and use cases I might have missed, so please chime in and we can figure out an algorithm that we can all agree on. I can send out the .xlsx file if people care to play with it at home.

So we’ve got six sets of scopes to deal with here, and they’re somewhat independent of each other. 

ClientReg - client registers for these scopes at the RS
RSTicket - RS requests a ticket with these scopes
ROPolicy - RO sets a policy with these scopes (and it’s fulfilled by the RqP for our purposes)
ClientReq - client requests these scopes at the token endpoint
RSReg - RS registers these scopes at RS setup time
PrevRPT - client presents a previously-held RPT that’s got some other scopes on it and it’s trying to augment that with new scopes

And finally what the token includes:

RPTResult - the sets that the resulting token includes on output

The one direct relationship seems to be that:

ROPolicy = subset(RSReg)

Because otherwise the RO could set scopes on a resource that the resource didn’t register, which doesn’t make sense to me. That’s the error in column “F” above. 

It’s clear to me that “ROPolicy” is a limiting set, in that if a scope is NOT in that set, then it is not in the result. In other words:

RPTResult = subset(ROPolicy)

That’s column D, and nearly any other combination without ROPolicy doesn’t let the scope go through, with one exception: if it’s in PrevRPT, it gets carried through no matter what. But in particular, that, I believe, is an AS decision on whether it wants to honor previous RPTs at all. That’s why I’ve coded those K, L in green.

This also means that RSReg is also a limiting set, due to transitive subset operations:

RPTResult = subset(RSReg)

We have both the client and RS request scopes for the token at runtime in their parts, and it makes a lot of sense to combine them. So we get a working set of:

Requested = union(ClientReq, RSTicket)

We have an open question with what to do with column I: if a client hasn’t requested a scope, and a ticket didn’t request a scope, but the client registered for a scope, do we include it or not? We could choose to either ignore it and leave it out entirely; or add it in, and if it passes ROPolicy then we’ll pass it through to the token. These were the options we were discussing on the call on Thursday. Ignoring it here would effectively ignore the client’s registered scopes entirely, which is valid. The alternative would be coded something like:

Requested = union(ClientReg, ClientReq, RSTicket)

This could also be done conditionally, like the case where the client didn’t specifically request anything:

if (empty(ClientReq)) {
Requested = union(ClientReg, RSTicket)
}

Or if the client or ticket didn’t request anything:

if (empty(ClientReq) && empty(RSTicket)) {
Requested = ClientReg
}

So my proposed implementation would be something like this horrible pseudocode:


if (ROPolicy is not subset(RSReg)) {
throw error and fail <<sanity check>>
}

<< the requested set is made up of the client’s request to the token endpoint and the RS’s request during the ticket issuance step>>
Requested = union(ClientReq, RSTicket)

<< if nothing’s been requested, maybe the client’s registered for something we can default to >>
if (empty(Requested)) {
Requested = ClientReg
}

<< finally, we take the requested scopes and filter out anything not in a matched policy, and add in anything from a previous RPT if it’s there >>

RPTResult = union(
intersection(Requested, ROPolicy),
PrevRPT)


I’ve tested a little bit of this with the following python truth table code:

from truths import Truths

print Truths(['ClientReg', 'RSTicket', 'ROPolicy', 'ClientReq', 'RSReg', 'PrevRPT'], ['(((ClientReq or RSTicket) if not (ClientReq or RSTicket) else ClientReg) and ROPolicy) or PrevRPT'])

This seems to match up to expectations on a quick inspection, but I’m potentially missing something. 

Hopefully this makes sense, and this reflects my current thinking on this topic. I have almost certainly missed some use cases and might have some cases that don’t reflect reality. 

 — Justin

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma