I don't want this to sound cavalier in any way, but I wonder if this is a place where consent receipts could "paper over" a lot of sins/variances. If there is a specific reason for going against a specific set of authorization data, or lack of authorization data, in a requesting party token, then surely an accounting of exactly what the variance was, with an explanation of the delta against the exact RPT contents, would be a godsend. A couple of thoughts on this idea: - I doubt UMA the spec is ready yet to make a normative reference out to MVCR, but the time seems right to experiment with the idea anyway. - Remember that the RPT that a client brought to the resource server associates that client, its requesting party, the authorization server, and that resource server; the RS may possibly have introspected it to reveal permissions (assume the default "bearer" token profile) that are associated with other resource owners, not just Alice. Any logging of permission data on Alice's behalf has to be privacy-sensitive and stick to what's relevant to her. - Andrew's Shoebox endpoint would be handy about now, so we'd have a nice place to send the receipt. (Alice's AS could choose to host that endpoint for her.) Time for someone (in CIS WG? this one??) to sketch out that spec? - I've observed in the past that the AS has no way, strictly speaking, of knowing whether the client actually did gain access to a resource vs. just attempted it and appeared to succeed based on observation of RPT contents vs. policy. The Shoebox endpoint would nicely do for this plain purpose ("I gave them access per this authorization data"/"I didn't give them access per this authorization data") as well as the more sophisticated purpose ("I gave them access for reason X even though they had authorization data Y"/"I didn't give them access for reason A even though they had authorization data B"). - We could have model clauses that cover each of the four circumstances so that anyone who requires reporting of whatever combination could pull in the necessary clauses. Finally, if this is a viable approach, then indeed Allan is right, and our current clause talking about having to disallow access is all wet. :-) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Dec 22, 2015 at 7:14 AM, Lisa Moon < lisa.moon@advocate-consulting.com> wrote:

Allan,

I don't know if this comment will be useful - but here goes.

Your final statement "My Concern is that the RS is ALWAYS the final arbitrator of access control, whether UMA, DAC or MAC. It should be able to modify its behavior based on local business rules and exceptions" exposes part of a much larger problem in consent management...namely, local interpretation of business rules related to privacy, etc.

Local interpretation creates a high degree of variance - making MANY rules difficult to operationalize. Keeping this in mind and finding a common standard, even at a basic technology level would help moderate the variance caused by local interpretation.

Lisa Moon Principal Consultant Advocate Consulting LLC (c) 952-913-7263 lisa.moon@advocate-consulting.com

On Mon, Dec 21, 2015 at 9:38 PM, Allan Foster <allan.foster@forgerock.com> wrote:

...

Folks, I am concerned about putting specific obligations on the RS and thus subjagating it to the AS.

Specifically to allow for Enterprise MAC with UMA participation, where the End user is a participant in the access control decision, but not the only participant.

1. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md>-Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md>: Delegate-Protection* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> and Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md> have mutually agreed to serve in these respective roles for each other, theResource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> gains an obligation to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md> to delegate protection services to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> for the set of protectable resources for which it represents this capability to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md>, and to respect the authorization data that the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_0.md> has associated with an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> when the Resource Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_0.md> subsequently allows or disallows access by the Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Client_0.md> that presented that RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> .

My concern here is that it delegates "Protection services" to the AS, and this feels a little like an all or nothing. This might not be true in the case where the RO is only one party in the Access control decision.

1. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md>-Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md>: Respect-Permissions* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> and Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> have mutually agreed to serve in these respective roles for each other, the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> gains an obligation to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> to disallow access by a Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Client_0.md> presenting an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> in all cases where the authorization data associated by the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_0.md> is insufficient for the access attempt..

The RS is obligated to dissallow access in the AS cannot provide sufficient rights - in all cases.

This has several implications. If the RS has additional business rules whereby a party might get access even tho they are not UMA authorized, (break glass?) (Admin or Help Desk) The RS HAS to determine if a user is a special user BEFORE making the request to the AS. Since once it has an answer, it is obligated to deny. This implies that the RS cannot opt out once the request to the AS is made.

It feels a little bit like don't ask don't tell!

My Concern is that the RS is ALWAYS the final arbitrator of access control, whether UMA, DAC or MAC. It should be able to modify its behavior based on local business rules and exceptions.

Allan

-- Simplify Email: Email Charter <http://emailcharter.org/>

[image: ForgeRock Logo] *Allan Foster - ForgeRock * *VP Strategic Partner Enablement* *Location:*San Francisco *p:* +1.214.755.9218 *email:* <allan.foster@forgerock.com>allan.foster@forgerock.com *blogs:* blogs.forgerock.com/GuruAllan *Skype:* Call GuruAllan <http://is.gd/lWVfMG> *www:* www.forgerock.com *www:* www.forgerock.org

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

You're right that the client presented the RPT in order to get access to a specific RO's "stuff", but technically (in the UMA sense), it doesn't strictly know that this is the case, and it's possible for its RPT to collect permissions that apply to the "stuff" that belongs to any of the ROs that use this RS. Core Sec 1.1.3 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#resource-api>: "An RPT binds a requesting party, the client being used by that party, the resource server at which protected resources of interest reside, and the authorization server that protects those resources. It is not specific to a single resource owner, though its internal authorization data components are likely to be bound in practice to individual resource owners, depending on the RPT profile in use." Core Sec 3.4.2 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#uma-bearer-token-profile> (part of the definition of what's returned when the RS introspects the token): "resource_set_id REQUIRED. A string that uniquely identifies the resource set, access to which has been granted to this client on behalf of this requesting party. The identifier MUST correspond to a resource set that was previously registered as protected." Even if the RPT contains lots of permission blocks for different resource owners, the resource server should be able to correlate the relevant resource set ID, for purposes of checking the client's access attempt, with its user -- the resource owner -- by virtue of the PAT it used to introspect the token. But it's theoretically possible that these resource set IDs, if badly constructed, all dumped to a big "comprehensive token contents" consent receipt, or correlated with badly protected PATs, could reveal a) the resource owner's identity used at the RS (none of the client/requesting party's business) and/or b) other resource owners at this resource owners' identities used at the same RS (also none of the client/requesting party's business). Other relevant spec snippets: Core Sec 8.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#rfc.section.8.1> (privacy consideration): "The authorization server comes to be in possession of resource set information that may reveal information about the resource owner, which the authorization server's trust relationship with the resource server is assumed to accommodate. However, the client is a less-trusted party -- in fact, entirely untrustworthy until authorization data is associated with its RPT. The more information about a resource set that is registered, the more risk of privacy compromise there is through a less-trusted authorization server." RSR Sec 5 <https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.html#rfc.section.5> (privacy considerations): "The communication between the authorization server and resource server may expose personally identifiable information of a resource owner. The context in which this API is used SHOULD account for its own unique privacy considerations." (Back when we used to use PUT and client-side ID creation vs. POST and server-side ID creation, we used to have a lot of text about ensuring randomness in ID creation for privacy. But hopefully well-constructed random resource set IDs are now baked into the cake.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Dec 22, 2015 at 10:19 AM, Adrian Gropper <agropper@healthurl.com> wrote:

On Tue, Dec 22, 2015 at 12:18 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

<snip>

- Remember that the RPT that a client brought to the resource server associates that client, its requesting party, the authorization server, and that resource server; the RS may possibly have introspected it to reveal permissions (assume the default "bearer" token profile) that are associated with other resource owners, not just Alice. Any logging of permission data on Alice's behalf has to be privacy-sensitive and stick to what's relevant to her.

<snip>

How and why does the RPT reveal permissions associated with other resource owners? Isn't the interaction between RS and Client always in a specific RO context?

Adrian Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

In fact, I may have been way too privacy-paranoid about this, based on our previous "PUT" design for resource set ID registration/creation. Others who would like to do some security/privacy analysis, check me on this thinking... - Each client of the AS's protection API -- that is, each RS -- asks for a resource set to be registered with a POST request. The RS isn't in control of the ID assigned to the resource set. - The server side -- the AS -- will, in response to the POST, create a strongly pseudorandom rsid for each resource set registered, in an identifier namespace across the *entire* universe of RS's (and their resource owners) using that AS. - An RS can map the resource set IDs to its specific service users (resource owners). It does this through the PAT it used when using the RSR endpoint -- that is, registering (creating, updating, reading, listing, deleting) resource sets. - The AS can also, of course, map the resource set IDs to the relevant resource owners through the PAT so that it can provide protection to those resource sets. - However, interestingly -- due to UMA's usage of OAuth in the AS/RS coupling -- it doesn't know what identity the resource owner uses to access ("log in to") the RS, and the RS doesn't know what identity the resource owner uses to access the AS. :-) So, let's imagine the resource set IDs get out into the wild -- hacked by Anonymous and published widely or something. :-) How much damage is done? Unless the RS is malicious and actively correlates this information with the PATs it has, or has incredibly bad I'm not sure I can see a way. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Dec 22, 2015 at 5:02 PM, Adrian Gropper <agropper@healthurl.com> wrote:

I'm not sure I understand, but it sounds like this is not a problem as long as the RO specifies the AS for herself. In that case, it's up to the AS to implement pairwise pseudonymity somehow if it wants to protect the RO's identity from correlation by malicious RS or C's. How the AS creates a separate AS URI for each RS would be out-of-scope for UMA.

Adrian

On Tue, Dec 22, 2015 at 7:21 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

You're right that the client presented the RPT in order to get access to a specific RO's "stuff", but technically (in the UMA sense), it doesn't strictly know that this is the case, and it's possible for its RPT to collect permissions that apply to the "stuff" that belongs to any of the ROs that use this RS.

Core Sec 1.1.3 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#resource-api>: "An RPT binds a requesting party, the client being used by that party, the resource server at which protected resources of interest reside, and the authorization server that protects those resources. It is not specific to a single resource owner, though its internal authorization data components are likely to be bound in practice to individual resource owners, depending on the RPT profile in use."

Core Sec 3.4.2 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#uma-bearer-token-profile> (part of the definition of what's returned when the RS introspects the token): "resource_set_id REQUIRED. A string that uniquely identifies the resource set, access to which has been granted to this client on behalf of this requesting party. The identifier MUST correspond to a resource set that was previously registered as protected."

Even if the RPT contains lots of permission blocks for different resource owners, the resource server should be able to correlate the relevant resource set ID, for purposes of checking the client's access attempt, with its user -- the resource owner -- by virtue of the PAT it used to introspect the token. But it's theoretically possible that these resource set IDs, if badly constructed, all dumped to a big "comprehensive token contents" consent receipt, or correlated with badly protected PATs, could reveal a) the resource owner's identity used at the RS (none of the client/requesting party's business) and/or b) other resource owners at this resource owners' identities used at the same RS (also none of the client/requesting party's business).

Other relevant spec snippets:

Core Sec 8.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#rfc.section.8.1> (privacy consideration): "The authorization server comes to be in possession of resource set information that may reveal information about the resource owner, which the authorization server's trust relationship with the resource server is assumed to accommodate. However, the client is a less-trusted party -- in fact, entirely untrustworthy until authorization data is associated with its RPT. The more information about a resource set that is registered, the more risk of privacy compromise there is through a less-trusted authorization server."

RSR Sec 5 <https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.html#rfc.section.5> (privacy considerations): "The communication between the authorization server and resource server may expose personally identifiable information of a resource owner. The context in which this API is used SHOULD account for its own unique privacy considerations."

(Back when we used to use PUT and client-side ID creation vs. POST and server-side ID creation, we used to have a lot of text about ensuring randomness in ID creation for privacy. But hopefully well-constructed random resource set IDs are now baked into the cake.)

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Dec 22, 2015 at 10:19 AM, Adrian Gropper <agropper@healthurl.com> wrote:

...

On Tue, Dec 22, 2015 at 12:18 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

<snip>

- Remember that the RPT that a client brought to the resource server associates that client, its requesting party, the authorization server, and that resource server; the RS may possibly have introspected it to reveal permissions (assume the default "bearer" token profile) that are associated with other resource owners, not just Alice. Any logging of permission data on Alice's behalf has to be privacy-sensitive and stick to what's relevant to her.

<snip>

How and why does the RPT reveal permissions associated with other resource owners? Isn't the interaction between RS and Client always in a specific RO context?

Adrian Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/