- WG-UMA - mailman.kantarainitiative.org

Scratch drafts for consideration tomorrow
by Eve Maler 16 Nov '17

16 Nov '17

Please take a look at the revisions in Grant Sec 3.3.1, 3.3.2, 5.7, and 6.2 (guided by this commit <https://github.com/KantaraInitiative/wg-uma/commit/1cc5e2e723ed11d3c96feed4…>) to see the proposed text for #358 <https://github.com/KantaraInitiative/wg-uma/issues/358> sub-issue (b). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Proposal for issue #358, sub-issues (a) and (b)
by Eve Maler 16 Nov '17

16 Nov '17

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-g…>: 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-p…> 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-p…> 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-p…> 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-p…>: 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

2 1

Agenda for UMA telecon 2017-11-16 (important meeting - please attend)
by Eve Maler 15 Nov '17

15 Nov '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-16 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-08-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-03>, UMA telecon 2017-08-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-17>, and UMA telecon 2017-09-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-09-14> - Finalization of Draft Recommendations - Issue #358 <https://github.com/KantaraInitiative/wg-uma/issues/358> resolution – see proposal in email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/QUDHjPWke…> - Consider motion to approve specs - Timeline - Progression of specs - Meeting schedule - UMA2 logo - New candidates to consider - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Distributed OAuth draft
by Justin Richer 15 Nov '17

15 Nov '17

Dick Hardt is proposing a Distributed OAuth system: https://tools.ietf.org/html/draft-hardt-oauth-distributed I've brought up that this is potentially related to UMA 2.0's solution space, and Dick has stated that he believes that they're solving a subset of UMA's problem space, and therefore don't need a lot of the functions and structure in UMA. Something to look into for people in this group, and perhaps even engage on the IETF side. -- Justin

2 1

Preparing for progressing the specs / discussing and deciding new issue #358
by Eve Maler 15 Nov '17

15 Nov '17

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 <https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+o…> document. In the meantime, we received a late-breaking issue from an external commenter that I put into issue #358 <https://github.com/KantaraInitiative/wg-uma/issues/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

6 10

Notes from UMA Legal telecon 2017-11-10
by Eve Maler 11 Nov '17

11 Nov '17

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2017-11-10 Attending: Eve, Jeff, Devon, Theresa, Mark, Kathleen, Tim, Ann, John Doc homework: - A very early section (the first?) should present the "pain point" by introducing several broad scenarios, including an Alice-to-Alice, Alice-to-Bob, and Alice-to-org, drawing from deliverable #1. It could introduce the language of "resource owner" and "requesting party". We could note that org-to-whoever sharing is out of scope for this exercise (framework). We could have a very high-level version of the x-and-y-axis scenario diagram that just talks about these two roles. and then the version with the three high-level scenarios. - In NewSec, we want to make the strongest case we can for our chosen legal devices, and ultimately for our biggest target type of toolkit (templates of some sort). - Later, we can get into the sub-scenarios we have collected, e.g., Alice as a guardian of a data subject too young to consent etc. The "collaborative diagrams" in the GSlides need more differentiation and "iconification". "Model clauses" specifically means they need regulatory approval, so how about "template clauses" or even "clause templates" or something? Templates will do for now. Let's get more specific about pain points. "Through a combination of strengthening data protection regulations, justified consumer cynicism and savviness about poor security and AdTech/MarTech ecosystems, and good rationales for data sharing, particularly in the cases of healthcare and the Internet of Things, we're seeing people start to be given just a little more transparency into and control of their personal data. Organizations have never had more incentives to make changes and reduce friction..." The healthcare construct of a "consent directive" can be directly and favorably compared to ToS opt-in (or, for that matter, opt-out – soon to be made effectively illegal by GDPR) as a mechanism for inviting individuals to express their data sharing preferences in ways that are not influenced by outside actors. UMA enables this construct to be digitized in a standard and repeatable way. This framework enables it to be AIs: - Eve: Create two new scenario diagrams ready to put into the GDoc: - Very high-level diagram introducing "RO" and "RqP" language - Fixed three-scenarios diagram - Tim: Flesh out the licensing framework itself - Possibly this includes the rationale as started in the comment on NewSec Be sure to see all the new comments in the doc. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Last Chance: Public review for comments and IPR review for Kantara Initiative UMA 2.0 Grant for OAuth 2.0 Authorization and Federated Authorization for UMA 2.0
by Megan Cannon 10 Nov '17

10 Nov '17

Dear Kantara Initiative Members and Community, This is a formal notice. Members of the Kantara Initiative User Managed Access Work Group (UMAWG) have recently concluded a round of public review, compiled comments, updated the original drafts, and approved the User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization and Federated Authorization for User-Managed Access (UMA) 2.0. The documents described below now enter a second 45-day public comment and IPR review period in preparation for a member ballot to consider their approval as Kantara Initiative Recommendations. Document 1: User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization (revision 08) Document 2: Federated Authorization for User-Managed Access (UMA) 2.0 (revision 08) Version: 2.0 Document Date: 2017-09-04 Document URLs: <https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html> User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization and <https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08. html> Federated Authorization for User-Managed Access (UMA) 2.0 To see a summary of comments and changes made related to the first public comment period, see this <https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+o f+Comments> Disposition of Comments document. Overview of Documents: User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization: This specification defines a means for a client, representing a requesting party, to use a permission ticket to request an OAuth 2.0 access token to gain access to a protected resource asynchronously from the time a resource owner authorizes access. Federated Authorization for User-Managed Access (UMA) 2.0: This specification defines a means for an UMA-enabled authorization server and resource server to be loosely coupled, or federated, in a resource owner context. This is an open invitation to comment. Kantara Initiative solicits feedback from potential users, developers and other interested parties, whether Kantara Initiative members or not, for the sake of improving the interoperability and quality of its technical work. Public Review and IPR Review Period Opens: 2017-09-28 Review period closes: 2017-11-12 at 11:59 UTC To Comment on the Specification: To comment please email your comments to <mailto:staff@kantarainitiative.org> staff(a)kantarainitiative.org with the subject "UMAWG COMMENT SUBMISSION" referencing the section or sub-section number, your comment and your proposed text to change. Intellectual Property Rights Notice: In accordance with the Kantara Initiative IPR Policy Article 5 and the Kantara Initiative Operating Procedures Article 6, you have a period of 45 days to review the draft specification for any Necessary Claims that may be implicated by the draft specification. While there is no requirement to review your patent portfolio for Necessary Claims, please be advised that unless you provide a licensing objection in accordance with the Kantara Initiative IPR Policy Article 5 or a notice of withdrawal in accordance with Kantara Initiative IPR Policy Article 6 on or before 2017-11-12 at 11:59 UTC, you will have committed to the licensing provisions as set forth by the Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non-Discriminatory (RAND) IPR Policy with respect to any Necessary Claims implicated by the final approved specification. Having signed the Group Participation Agreement (GPA) all members of the UMAWG should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved Kantara Initiative specification. Kantara Initiative invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification so that these notices may be provided to the UMAWG. To submit an IPR Necessary Claim, email <mailto:staff@kantarainitiative.org> staff(a)kantarainitiative.org with the subject "UMAWG IPR CLAIM". Please contact the Kantara Initiative staff at <mailto:staff@kantarainitiative.org> staff(a)kantarainitiative.org with any questions regarding this notice. Best Regards, Megan Cannon Megan Cannon | Program Manager | Kantara D: +1.781.876.6287 | M: +1.781.258.5523 megan(a)kantarainitiative.org <mailto:megan@kantarainitiative.org> kantarainitiative.org <http://www.kantarainitiative.org/> 401 Edgewater Place, Suite 600, Wakefield, MA, 01880 USA

1 0

Legal call is a yes for tomorrow
by Eve Maler 09 Nov '17

09 Nov '17

Talk to you all then. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Yes, Legal is meeting tomorrow
by Eve Maler 02 Nov '17

02 Nov '17

We won’t have Tim with us. He’s asked us to focus on figuring out which diagrams to use to accompany the text, starting with the sharing scenarios. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Upcoming meetings and timeline for the 2.0 specs
by Eve Maler 31 Oct '17

31 Oct '17

Hi folks-- Unless someone raises a hand to discuss something more urgently, here is what I suggest for a timeline in the upcoming weeks (Legal calls will proceed apace): - Thursday Nov 2: no meeting (this week) - Thursday Nov 9: no meeting (next week) - Sunday Nov 12: second public comment period ends at 11:59 UTC - *Monday Nov 13: e-ballot starts*, to approve the Draft Recommendations as amended and forward them to the LC for certification for All-Member Ballot (see below) - *Thursday Nov 16: quorate meeting to review where we are, possibly foreshorten e-ballot, look at logos...* There are currently three outstanding issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>. Two are editorial and easily disposed of. One is Pedro's issue, which is intended to be a suggestion for an extension rather than a new V2.0 feature. (Since the issue was submitted during the second public comment period, I just wanted to make this clear, so it's not a surprise when we take no action at this stage and record it in the Disposition of Comments document.) Assuming there are no more comments, I'll plan to prepare a rev 09 of Grant for the occasion of the Nov 13 e-ballot (FedAuthz is currently unaffected by the comments). We'll revise as necessary depending on what other comments come in. Please let me know if you have any questions. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0