(Pre-responding to Cigdem's point sent to the draft minutes thread, in
order to encourage discussion here...) Since UMA conceives of the RS as
more of an independent actor than OAuth does, we haven't to date seen it as
"just a messenger". But we could potentially interpret its
permission-requesting actions as such, if a clear case can be made.
But given that the RS has a lot of interpretation power over exactly what a
resource is, and neither the AS nor the client has visibility into that
interpretation, it will have to have at least enough independent control to
impose its interpretation at that permission-requesting point.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Wed, Nov 30, 2016 at 8:37 PM, Eve Maler
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.)
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl