I did reach out to the issue #358 https://github.com/KantaraInitiative/wg-uma/issues/358 commenter but haven't heard back about which interpretation they meant: - Sub-issue *(a)*: A concern about the existence of the authorization server as a separate service learning PII (vs. the service actually holding the protected resources), about the notion of "outsourcing" authorization, and about arbitrary claims being passed vs. the minimum possible. - Sub-issue *(b)*: A concern about claims being sent (pushed) by a potentially malicious client seeking access to a protected resource without authorization by the requesting party using that client. In the absence of some indication directly from the commenter, the more I think about it, the evidence weighs in favor of sub-issue *(a)* because of this text: The real-world analogy is the key master of a room. The key master is responsible for issuing and revoking keys and for knowing who those keys are given to; the keys themselves do not contain information about the person holding that key. This passage is about the server side, not the client side. So I *propose the following concise rationale* for not changing UMA's design... One of the important benefits of UMA is to provide formal separation between the "keymaster" (roughly, PDP) and the "gatekeeper" (roughly, PEP), with trust established between them in the resource owner's context through OAuth. And indeed the "key" (access token/permissions) doesn't contain information about the "person" (requesting party/client pair) holding it; the keymaster assesses claims (which may or may not be related to personal information) as necessary before issuing it to the person. Then the gatekeeper is able to check with the keymaster about the key's exact shape and compare it to the tumblers of its lock. ...where a whole raft of benefits attach to this separation but we don't have to go into it in detail. (Hmm: http://ghostbusters.wikia.com/wiki/Zuul... New UMA presentation?) As for sub-issue *(b)*, given that it seems to deserve additional security consideration, here is some concrete text to layer on top of the text I quoted in the thread already. If no one else has a different proposal, I would like us to consider this *immediately*, and decide formally tomorrow. The *approach* is to sequester the advice into the right places and then efficiently point to it. The *rationales* for making the new Sec 5.7 text a RECOMMEND (vs. a MUST) are that we're already recommending for AS's not to accept pushed claim tokens from untrusted clients and discussing the likely use case when claim pushing makes good sense (AS-as-IdP, client-as-RP) -- and it's impractical for force compliance on a security consideration that has so many deployment ecosystem "BLT" variables. - Grant Sec 3.3.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#uma-gr...: Client Request to Authorization Server for RPT - claim_token: "The client MAY provide this information on both first and subsequent requests to this endpoint." - *ADD after this or the next sentence:* See Section 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#trust-... and Section 6.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#rqp-pr... for security and privacy considerations regarding pushing of claims containing personal data. - pct: "Given that some claims represented by a PCT are likely to contain identity information about a requesting party, a client supplying a PCT in its RPT request MUST make a best effort to ensure that the requesting party using the client now is the same as the requesting party that was associated with the PCT when it was issued." - *ADD after this sentence:* See Section 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#trust-... and Section 6.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#rqp-pr... for additional security and privacy considerations regarding persistence of claims containing personal data. - Grant Sec 3.3.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#claim-...: Client Redirect of Requesting Party to Authorization Server for Interactive Claims-Gathering - "The client redirects an end-user requesting party to the authorization server's claims interaction endpoint for one or more interactive claims-gathering processes as the authorization server requires. These can include direct interactions, such as account registration and authentication local to the authorization server as an identity provider, filling out a questionnaire, or asking the user to authorize persistent storage of any collected claims to optimize future authorization processes; this last example could potentially be associated with the authorization server's subsequent issuance of a PCT." - I noticed the example list is a bit incomplete, so I'm building in a slightly *extended editorial suggestion* here. See italic portions. *REVISE as follows:* "...These can include account registration and authentication local to the authorization server as an identity provider, *federated interactions with the authorization server as a relying party*, filling out a questionnaire, or asking the user to authorize *subsequent collection of claims by interaction or pushing, and persistent storage (for example, as associated with a PCT). See Section 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#trust-... and Section 6.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#rqp-pr... for security and privacy considerations regarding pushing and persistence of claims containing personal data*." - "In order for the client to redirect the requesting party immediately on receiving the initial permission ticket from the resource server, this process assumes that the authorization server has statically declared its claims interaction endpoint in its discovery document." - *NO CHANGE needed here:* This is just a mechanical consideration to be referred to from the security consideration. - Grant Sec 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#trust-...: Requirements for Pre-Established Trust Regarding Claim Tokens - *ADD to second sentence of second paragraph:* "It is RECOMMENDED to document how the client, authorization server, *requesting party*, and any additional ecosystem entities and parties will establish a trust relationship and communicate any required keying material in a claim token profile, as described in Section 4." - *ADD new final paragraph:* "A malicious client could push a claim token to the authorization server to seek access to a protected resource on its own behalf without, or prior to, the authorization server using interactive claims gathering to seek an end-user requesting party's authorization. In so doing, it could reveal the requesting party's personal data. It is RECOMMENDED for trust relationships established by the ecosystem parties either to include prior requesting party authorization as required, or for end-user requesting party authorization to be gathered interactively prior to claims pushing, as described in Section 3.3.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#claim-... . " - Grant Sec 6.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#rqp-pr...: Requesting Party Information at the Authorization Server - *CHANGE second sentence of second para:* "It is also RECOMMENDED for the authorization server to use an interactive claims-gathering flow to ask an end-user requesting party *for authorization to collect any claims subsequently and to persist their claims (for example, before issuing a PCT), if no prior authorization has been established among the ecosystem parties (see Section 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html#trust-...)* ." *Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl