- WG-UMA - mailman.kantarainitiative.org

We have a Legal call tomorrow
by Eve Maler 16 Nov '17

16 Nov '17

Also: Please note that on Nov 30, Legal subgroup denizens are invited to join a joint UMA WG/Consent and Information Sharing WG call at 8am PT to discuss touchpoints. We'll use their GoToMeeting dial-in. Stay tuned for details. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-11-16
by Eve Maler 16 Nov '17

16 Nov '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-16 MinutesRoll call Quorum was reached. Approve minutes 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>: APPROVED. 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…> Regarding #358a: Consensus that we can respond to the commenter with "no change" and the keymaster/gatekeeper rationale. Regarding #358b: When UMA1 had the AAT, we presumed that the RqP's authorization was captured in some fashion, even if the token issuance was silent – but really, we're in the same boat now. Whatever trust framework applied to AAT issuance before needs to apply to RqP authorization now, and we're shoring up our considerations for saying so. Editorial instructions: - In 3.3.1 and 3.3.2: Should we say "...regarding claims containing personal data" or just "*...regarding claims*" when pointing people to the security and privacy considerations? *The latter.* - In 5.7: For "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." instead say "*A malicious client could push a claim token to the authorization server (revealing the claims therein; see Section 6.2) to seek resource access on its own behalf prior to any opportunity for an end-user requesting party to authorize claims collection.*" - Note that OAuth Authorization Server Metadata (Discovery) was updated to rev 07 <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-disc…> - Now requires the https: scheme - There are some other changes as well, but perhaps less impactful to us - Consider motion to approve specs MOTION: Andi moves and Maciej seconds: "Approve Draft Recommendations Grant rev 09 and FedAuthz rev 09 as amended according to the editorial instructions of UMA telecon 2017-11-16, as ready to send to the Leadership Council for certification towards an All-Member Ballot." APPROVED by acclamation. Woot. Timeline - Progression of specs What happens next: Assuming we have a successful motion today, the Draft Recommendations will go to the LC for an e-ballot to certify them for a Kantara All-Member Ballot. Eve has prepared a GOTV spreadsheet so that we can all help reach out to Kantara Members and efficiently boost the Yes votes. - Meeting schedule Andrew and Eve have worked up a plan to have the CIS and UMA WGs meet on Nov 30 at 8-9am PT, just before the regular UMA WG call time and overlapping the CIS WG Consent Receipts call time. We will invite CIS, UMA, UMA Legal. Planned for 60 minutes but could go into the UMA WG hour (using the CISWG GTM line). Kantara has switched to GoToMeeting instead of TurboBridge. We won't switch to GTM yet, so as not to disrupt our current processes, but let's look into that as soon as practicable. Agenda: - CR people present on CR to UMA people - UMA people present on UMA to CR people, including reviewing the "shoebox" labeled issues - UMA Legal people present on UMA Legal to all - Enumerate the possible places in UMA where things would be useful to "record"/have a "receipt" structure - Enumerate places where the RO and RqP would find it useful to get a receipt ("repudiation" use cases) - Enumerate relevant technical artifacts in UMA and their places of issuance and usage UMA logo - New candidates to consider Notes on options from Domenico (shown on screen): - Great direction - Interest is highest in the rightmost option - Since there isn't huge awareness of UMA1, how about dropping the "2"? - It would be good to see options adding back the Kantara green color somehow even with the "2" gone - Circular is good, making it similar to the OAuth family - The original UMA logo is beautiful, but the white color of the third bubble is sometimes a challenge on white backgrounds, making it look off-center Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Sal 2. Andi 3. Maciej 4. Eve 5. Mike Non-voting participants: - James Regrets: - Domenico - Adrian *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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