Yes, that wording is pretty old; we’d have to modernize it if we’re interested in it. Basing it on the wording we have now, it could be something like:

"If the client's request at the protected resource has a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client, it SHOULD provide access to the desired resource. Reasons for not providing access include, for example, a need to apply additional application-specific security checks.”

Since a SHOULD should always be accompanied by a rationale for not following the SHOULD, giving this example seems apt. (And since it’s security-related, it sort of harks back to the statement in the intro that “The recipient of each request message SHOULD respond unless it detects a security concern…”.)

Also note that since the RS is in total control of when it starts using the UMA header in responses, it could apply "application-specific security checks” before starting the UMA dance and we’d be none the wiser.

p.s. I believe that this entire idea falls into the same category of patch-release logic as the rest of the #163/#163/#168 discussion. :-)

On 1 Sep 2015, at 7:06 PM, Maciej Machulak <maciej.machulak@gmail.com> wrote:

Eve,

I would also clarify what a "valid access token" means. Bear in mind that a token can be valid but may not have the necessary permissions for this resource, right?

Cheers,
Maciej

On 2 September 2015 at 02:47, Eve Maler <eve@xmlgrrl.com> wrote:
Maybe one more while I’m at it:

Inspired by Farazath’s recent question; the discussion and resolution of #163/#164/#168 concluding that the RS has quite a lot of HTTP status discretion; and this wording in Core Sec 3.5... “assuming the resource server chooses to respond to the client, it MUST give access to the desired resource” , I’m thinking we should reassess old issue #15: Must the host [RS] give access if the requester [client] has suitable permission?.

At the time, we resolved it with softer wording than we have now — “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." — but we apparently never published the softer wording as an I-D, and undid the decision by rev 03.

I remember that we discussed just keeping MUST because there’s nothing UMA can do about the RS’s actions, but it may make sense to be clear to RS developers and deployers that UMA is “discretionary access control”, and an RS always has the right to refuse service (so to speak), same as an authentication RP.

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com