Thanks all

Your consideration of this is both much appreciated and necessary, not least because it forms a provable trail that the matter is being given deep consideration. 

I am not directly and deeply involved in every detail of UMA so it is possible I am way off the mark.  But when I looked at the comment, my first thought was that the commenter may not have been fully aware of the context and background of UMA.

The phraseology used was reminiscent of what I might describe as 'classic' thinking - good, logical and understandable in its own way.

But UMA, like many Kantara specifications that Kantara member volunteers and non member participants contribute to solve known industry issues, can be disruptive as it breaks new ground.

Is it possible that there might be some 'over-thinking' by the Group in trying to respond to this comment?
 
Not taking anything away from any comment .. but just sayin'.. 

Kind regards
Colin

Executive Director
Cell: +44 (0)7490 266 778






On Tue, Nov 14, 2017 at 5:27 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Andi, thanks for the thorough writeup on GitHub.

James and I have just been discussing this. I had a little trouble understanding his interpretation until I mentally mapped "claims submission" onto "claims pushing" -- and "relying party" very roughly onto "requesting party"! Now I get it.

It's not clear which interpretation our commenter means; I'm going to ask Kantara staff to reach out and see if I can have a dialog with them just to clarify. But in any case, let's treat this potentially as two sub-issues:
  • Sub-issue (a) (responses from Adrian, me, Andi): 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) (response from James): 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.
If I can establish that the commenter's concern is (b), we don't need to respond formally to (a). If their concern is indeed (a), we do need to respond to it (and I think we have plenty of fodder for a rationale for "no change"), but we should take a look at (b) regardless. You can't un-ring a bell.

Here is my comment on (b).

James proposes we take one of two actions: remove claims pushing entirely, OR add a privacy consideration. The commenter pointed to an existing privacy consideration in Grant Sec 6.2, but it seems to me that this issue is, rather, a security challenge ("malicious client"). It turns out we already have a relevant security consideration section, Grant Sec 5.7 (Requirements for Pre-Established Trust Regarding Claim Tokens). Since the use cases for claims pushing are pretty well-documented in that section, does it make sense to enhance that section with RqP authorization comments and tie that in with some additional comments at the following points?
  • Grant Sec 3.3.1: Client Request to Authorization Server for RPT
    • claim_token: "The client MAY provide this information on both first and subsequent requests to this endpoint."
    • 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."
  • Grant Sec 3.3.2: Resource Server Response to Client on Permission Request Failure
    • "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."
    • "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."
  • Do we actually need an additional privacy consideration to match the security consideration? Or need to enhance the text in Sec 6.2?
Thoughts?


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


On Tue, Nov 14, 2017 at 3:11 AM, James Phillpotts <james.phillpotts@forgerock.com> wrote:
As I read it, this is talking about the possibility of a malicious client gaining access to resources by impersonating the requesting party:

1. The malicious client learns that AcmeAS supports claims submission of some form that it can acquire*, and that AcmeRS always uses AcmeAS as its authorization server
2. The client sets itself up to acquire claims in that form about Bob, through some seemingly unrelated operation on its own service, without mentioning AcmeRS or AcmeAS.
3. The client requests resources at AcmeRS out of band, receives a ticket, and presents it along with claims about a user to AcmeAS
4. The client gains an access token in the Bob's name without Bob knowing about it.

* I'm trying not to get hung up about what form the claims might be in that the client can acquire them, but for example, if the client knows that AcmeAS doesn't properly check the audience of ID Tokens, then an ID Token from a supported IdP would be one such form.

This seems like a legitimate concern about claims submission by the Client. Assuming that it is, I don't think we can take no action. We can either (a) remove claim submission by the client completely, (b) add a privacy clause stating that the AS MUST NOT support claims submission from the Client unless the deployment is a closed ecosystem in which it can be sure the client has given consent for its credentials to be used without direct consent, or (c) something else...? Option (a) is probably the strongest, but least desirable, where as option (b) is much weaker.

Cheers
James

On 14 November 2017 at 10:37, Andrew Hindle <andrew@hindleconsulting.com> wrote:
I made a comment in GitHub.
Unless I fundamentally misunderstood what the comment was getting at (which is entirely possible), I concur with Eve's assessment.

--&e


On Tue, Nov 14, 2017 at 12:45 AM, Eve Maler <eve@xmlgrrl.com> wrote:
I would like to close discussion of issue #358 before our Thursday call. This is a request for WG participants to speak up by Wednesday if they believe any concrete change should be made to the specifications in response to the comment.

Note that the comment does not request any specific changes. However, it mentions a few concepts that are -- if everything were read at face value -- seemingly contrary to UMA's base architecture:
  1. Relying party/resource server being the exclusive entity (vs. the resource owner, the "user" in User-Managed Access) to authorize access
  2. Relying party/resource server being the exclusive entity (vs. the authorization server, for the GDPR liability rationale Adrian gave and the scalability and the central monitoring and management user convenience rationales I gave) to collect claims
  3. Claims consisting only of an identity credential/credential score (vs. a full variety of claim types, including non-identity/non-uniquely identifying credentials, as motivated by the examples I provided)
  4. Claims only being about the client (vs. the requesting party -- I think they must have meant the requesting party, thinking about the discussion of privacy concerns with the claims)
The focus seems mainly on nos. 2 and 3.

If no one recommends a specific change, then I propose that we take no spec action in response to the comment, with the provided rationales. 


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


On Mon, Nov 13, 2017 at 2:18 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Oh yes, in addition to Adrian's note and my last one, I also wanted to mention the UMA legal framework effort. The framework is intended to map technical UMA artifacts to legal devices such as contracts and licenses, and to enable the usage of these devices in a manner consistent with protecting privacy rights. 


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


On Mon, Nov 13, 2017 at 11:48 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Some brief thoughts from me. Scratching any of the itches, do you think?

====
The concern seems to be that the resource owner's authorization server must generally learn claims about the requesting party in order for the latter to satisfy policy conditions and gain access to protected resources.

Indeed, UMA's Federated Authorization specification optionally enables a resource server to formally outsource resource protection to an authorization server, an access control architecture sometimes described in terms of a "policy decision point/policy enforcement point" split. This has value in that it enables the resource server to become simply a "relying party for authorization services", doing much less work itself and being able to scale better. If UMA is not used to assess claims at an authorization server, then each resource server has to collect and assess claims itself, which spreads the claims further. It also enables the resource owner to monitor and manage resource sharing from a single service.

With regard to only requiring the requesting party to reveal a "credential score": There are use cases for Alice choosing to share resources on the basis of non-uniquely identifiable claims, for example, "prove you are a citizen of country X", or "prove possession of a one-time code or token". For these use cases (explored in this talk), a single "credential score" may not work so well.

(UMA does explicitly allow resource servers to add their own checking. "... [T]he resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." See this section. Thus, outside the scope of UMA, resource servers can "use their own sources of information about the client" and requesting party as they see fit.)

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


On Sun, Nov 12, 2017 at 10:03 AM, Adrian Gropper <agropper@healthurl.com> wrote:

Adrian

On Sun, Nov 12, 2017 at 12:14 PM Eve Maler <eve@xmlgrrl.com> wrote:
I've edited the Grant spec to take care of the two outstanding editorial issues (but haven't published it yet), and also the Disposition of Comments document. In the meantime, we received a late-breaking issue from an external commenter that I put into issue #358. I'll duplicate the text here so we can hopefully discuss and decide it efficiently, in email and if necessary in our upcoming call on Thursday:

Authorization should be under the purview of the relying party

Referencing sections 3.3.1, 3.3.2, 3.3.4, and 6.2 of the UMA 2.0 Grant for OAuth 2.0 Authorization, our comments are as follows.

Authorization of a client should strictly be under the purview of the relying party, who would use their own sources of information about the client to determine that authorization. Including any information beyond an identity credential score with the credential itself invites invasion of privacy and trackability. Claims, then, should not contain personally identifiable nor sensitive information. Authorization must be separate from authentication.

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.

Please weigh in with your comments. I will try and do so myself when I get a chance later tonight.

The goal is to wrap up all outstanding issues (as of now, this is the only one; the comment period closes at 11:59 UTC today) ASAP and vote out the (edited as required) specs for the LC to certify as ready for All-Member Ballot.

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

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

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.




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




--
Andrew Hindle
Hindle Consulting Limited

Hindle Consulting Limited is a company registered in England and Wales.  Company number: 8888564.
Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.

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



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



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