Must the host give access if the requester has suitable permission?

[findthomas]

MUST the host give access if the requester has suitable permission? (Someone want to take this AI?)

[Previously #40]

[findthomas]

From UMA Meeting minutes: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-11-03

Issue #15: Must the host give access if the requester has suitable permission?

• Paul: Short answer: no.

• Paul: Longer answer: as, discussed last week: UMA is focused on discretionary access control (DAC). Mandatory access control (MAC) is out of UMA scope. Host SHOULD give access if the requester has suitable permission. Discretionary access control should not override mandatory access controls.

• Paul takes AI to comment on this ticket in GitHub, modify the spec to SHOULD, and close the issue.

[findthomas]

From UMA Meeting Minutes: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-10-27

George has a concern about the host's new REQUIREment to let a requester in if the permissions are correct, even if it sniffs something wrong with, say, the requester's IP address. Originally we'd said SHOULD. There are a couple of arguments you could use for making the SHOULD case: For one, the host may be under the constraints of mandatory access controls that would militate against giving access despite the advice from the AM. For another, this takes away the host's ability to do risk-based assessments. Ultimately, hosts need to mitigate their very probable real-world liabilities if something was obviously wrong about the access attempt. The rationale for a MUST is that any MACs (vs. discretionary access controls) are at a layer other than the UMA layer. George points out that REST collapses all layers into one, in a sense. The host could respond in those cases with 403, or 500. If a host elects to deny access according to its own judgment in opposition to the AM's response of a perfectly valid token with perfectly valid and active permissions, or even prior to talking to the AM in the first place, perhaps we should say that the host is free to give any HTTP error that suits the circumstances.

Should we distinguish between transient errors and fatal errors? This would provide a hint to the requester about what else to try, vs. telling the user "Sorry, what you were trying won't work." HTTP's errors do have some semantics around this. Client errors generally mean that the client did something wrong, and they should try again and do it right. 503 (Server Not Available) is another example of an obviously transient (retryable) vs. fatal (non-retryable) error.

We have consensus to move back to a SHOULD basis for this language, ideally providing an explanation about how the host is still at liberty to control its own access control policies as long as they're tighter than the AM's.

This closes issue #15.

[findthomas]

Added the following text to Section 3.1.3:

"When a requester presents a valid access token, the host SHOULD provide the requester with access to the desired resource. Note that that access to resources at a host remains at the discretion of the host, even in cases where the requester has presented a valid access token."

[xmlgrrl]

Having moved, just after this decision, back to MUST language, the WG decided in UMA telecon 2015-09-03 to revise this and related wording related to the V1.0.1 release.