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):
- (Client can bring no RPT and ask for one -- not a concern)
- (AS can issue a new RPT A -- not a concern)
- 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
- AS is allowed to reissue the existing RPT A (same RPT string), having added the relevant permissions to it
- AS can issue a new RPT B (different RPT string), having added the relevant permissions to it
- AS can invalidate the old RPT A that the client brought it upon this action
- 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.