I'd like to try and structure our discussion for talking about set math, and also a use case that is hopefully just complex enough for discussion. (If this use case spurs ideas for other contrasting/better use cases, let's try and formulate them in a similar fashion for comparison's sake.) Thanks to Vlad on the APAC sync call for helping me think this through!
The relevant sequence is:
(Long before) RS publishes API and its scopes, and client is developed according to those scopes
Say anything at all about this in the spec?
(Long before) Client registers with RS/API publisher to use only those scopes it intends to use
Does this make sense to tackle in the spec at any level?
Client attempts resource access at RS with no token -- giving no further overt context to the RS about what it wants
RS requests permission(s) on client's behalf at AS, based on knowledge of the parameters of the attempt
Used to be called "registering a permission" and it had to be singular, but it's now called "requesting permissions on behalf of the client" and can be plural (multiple resources)
Right now, as it was in UMA1, we require the RS to request permissions that are "sufficient" for the client's access attempt -- this is up for discussion
Client brings permission ticket from RS to RS, requesting an RPT
Client couldn't ask for specific scopes before, but now it optionally can
After the authorization process, if success, AS grants some set of permissions
Right now, as it was in UMA1, the AS is allowed to grant some permissions or no permissions if it's the case that only some of the RO's policy conditions were satisfied -- this is up for discussion
Use case:
Alice uses an UMA-protected cloud file system API (RS), with files and folders as protectable resources.
Folders have scopes read, write, and search.
Files have scopes read, write, and execute.
Folders can contain files and other folders, and any one file can more than one "folder parent". However, this is known only to the RS, not to the AS.
The RS is able to tell a distinct RO and AS for every location URI for a file or folder by means of an internal mapping process.
Alice has resources with names as follows (let's use the name as the ID, for clarity of discussion):
folder "deciduous-trees'
folder "evergreen-trees"
file "birch" in folder "deciduous-trees'
file "larch" in folder "deciduous-trees'
file "fir" in folder "evergreen-trees'
file "yew" in folder "deciduous-trees' and folder "evergreen-trees"
We need to answer the following questions (and which others?):
The client attempts to read file "birch".
Presumably the RS can request permission birch:read from the AS on the client's behalf. Can it request:
birch:read+write and also larch:read+write?
Only deciduous-trees:read without birch:read if its access control semantics (something like "folders contain/cover files") means that access to a folder confers access to contained files?
Only birch:write? Our current UMA1-based wording says no since this wouldn't be sufficient for what the client attempted.
What other permutations?
The client attempts to write a change to file "yew". The RS requests permission for yew:write on the client's behalf (definitely okay). The client takes the resulting permission ticket to the AS's token endpoint.
If the client includes no scopes in its request for an RPT:
If it meets the operative policy conditions only for "write", can we assume that the AS should only ever issue a permission for yew:write?
Are there any circumstances in which having the AS "surround"/extend what the RS requested ever makes sense, such as issuing a permission for yew:read+write or perhaps deciduous-trees:write and evergreen-trees:write?
If the client includes scopes in its request for an RPT, such as read and execute (keeping in mind that the client knows nothing about resource IDs per se and that scopes can differ per "resource type" as they do in this example):
Should the RS interpret this request as referring to the "closest" applicable resource, such as the file on which access was attempted in this case? The "execute" scope only makes sense on files, not folders. What if this logic doesn't make sense in the case of some other API? (We have written up an "invalid_scope" error already, but it may be underspecified.)