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 server2. 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 AcmeAS4. 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.CheersJamesOn 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.--&eOn 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:The focus seems mainly on nos. 2 and 3.
- Relying party/resource server being the exclusive entity (vs. the resource owner, the "user" in User-Managed Access) to authorize access
- 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
- 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)
- 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)
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.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.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.)On Sun, Nov 12, 2017 at 10:03 AM, Adrian Gropper <agropper@healthurl.com> wrote:I think this paper relates to this issue: https://github.com/WebOfTrustInfo/rebooting-the-web-o f-trust-fall2017/blob/master/f inal-documents/identity-hubs-c apabilities-perspective.pdf AdrianOn 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 partyReferencing 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._________________
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
--
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