Set math discussion setup
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
(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 <eve@xmlgrrl.com> wrote:
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
Hello, I tried to think over the questions for the first bullet in the use cases. My questions/comments come after the use case (starting with “Cigdem:” bold text) 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? Cigdem: Can another permutation be? RS registers only permission birch: read. In authorization assessment stage, AS checks permissions for birch for the specific client, given by RO. If they include write or execute, then may the AS return a token with birch:read, birch:write, birch:execute? This may be useful if the client is expected to attempt a write after a read. Here, AS expands the token based on the RO permissions (assuming client can handle these scopes, registered for them etc., which is another parallel discussion). To me, the answers to these questions will depend on how the resources were registered for protection in the first place, and what granularity the resource owner grants permissions. AS will not know the file/folder structure and will operate on which resources were registered. So, does the resource server register a file and, separately its encompassing folder? Does RO create policies separately at both file and folder level? i.e., does RO allow some clients access to specific files within folders, and some others to an entire folder and everything underneath it? In the first suggestion, if RS asks for birch:read+write and larch:read+write, and these resources are registered at AS and scopes are valid, AS will return a permission ticket. When the client presents the permission ticket, if the client is only permissioned to read birch then, I expect, AS will scope down the request (but client did not ask for that action in the first place). Per UMA text, alternatively, the AS may interact with the RO to authorize access attempt in near-real time to get permission for larch:read+write . But, the client has not attempted access to larch and did not even want a write. Finally, let’s assume RS registered a permission for deciduous-trees:read. If the RO did not give permissions at the folder level to this client, should the AS reject or try to return a minimum token for the folders in that folder? But then AS does not know the folder structure. If birch was registered separately, then it may be that RO gave permission only to birch:read. If the request is rejected, this is confusing, because the client asked only for birch:read and its request is denied because the RS registered an elevated permission. In this case, the policy at the AS does not need fixing, neither the AS behavior. But RS should not have elevated the permission request. Can RS reliably make decisions on which requests to elevate without knowing RO policies (which only AS knows)? Thanks, --Cigdem Eve Maler Cell +1 425.345.6756<tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
participants (1)
-
Cigdem Sengul -
Eve Maler