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-a...:
"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...
(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.sectio...
(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#...
(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
On Tue, Dec 22, 2015 at 12:18 PM, Eve Maler
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/