- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2017-11-30 (joint with CIS WG; starts an hour earlier; different dial-in)
by Eve Maler 29 Nov '17

29 Nov '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-30 Date and Time - *Special time, Thursday 8am PT *(scheduled for 1 hour, assuming it will run longer!) - Special dial-in for today: CIS WG GoToMeeting line (see calendar link below for additional details): https://global.gotomeeting.com/join/323930725 <https://www.google.com/url?q=https%3A%2F%2Fglobal.gotomeeting.com%2Fjoin%2F…> - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda for joint meeting - Consent Receipts people present on Consent Receipts to UMA people - UMA people present on UMA to Consent Receipts people, including reviewing the GitHub issues labeled "shoebox" <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> - 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 UMA resource owner and requesting party would find it useful to get a receipt ("repudiation" use cases) - Enumerate relevant technical artifacts in UMA and their places of issuance and usage - Record next steps - At 9am PT take a quick break for: - Update on spec timeline progress and GOTV efforts - Update on new logo selection - Update on plan to switch to GoToMeeting in 2018 - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder about our joint meeting with the CIS WG on Nov 30
by Eve Maler 27 Nov '17

27 Nov '17

I've added an event to our calendar for 8am PT this Thursday, just before our regular hour, and we'll be using the CIS WG's GoToMeeting line. It has an agenda in it. If we go over, we'll just keep using the GTM line, instead of our join.me. If anyone would like to be explicitly added to the invitation, please let me know. (And I've been noticing that there are a lot of people on the existing weekly invitation who don't attend regularly, so I'm going to drop them so they're not bothered by this stuff. If you want to be retained on these anyway, let me know.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMAnitarian holiday get-together in London
by Eve Maler 25 Nov '17

25 Nov '17

Hi all-- Who might be available/interested to get together in London on the 14th or 15th, lunchtime or afternoon or evening, for a little holiday celebration? I'll be in town. I've created a Doodle poll to capture preferences. https://doodle.com/poll/hr3nm6yprncqi2q9 Please let me know by end of next week (Dec 1), if you can, so I can make arrangements! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Breaking: The LC has certified our Draft Recommendations
by Eve Maler 22 Nov '17

22 Nov '17

Next stop: The All-Member Ballot to approve our specifications as Recommendations will start on Monday and will run for fourteen days (Nov 27-Dec 11). So it will shortly be time to gear up for our GOTV (Get Out The Vote) effort! In the meantime, I hope those of you who celebrate US Thanksgiving have a very happy one. Talk to y'all on the 30th. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: No WG or Legal meeting this week
by Eve Maler 22 Nov '17

22 Nov '17

Also, I heard back from our commenter on issue #358, who reported that sub-issue (a) was the correct interpretation, and they noted our disposition of the comment. I added that the UMA Legal work may be of interest; they agreed (paraphrasing) that non-technical solutions would help with the potential problem with PII exposure they reported. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

17 Nov '17

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2017-11-17 Attending: Eve, Jim, Tim, Kathleen, Colin, Bjorn, Mark Tim asked: To avoid many many contracts, is it possible to have all parties go through the ASO? - Eve: Most circumstances today leave Alice accepting the ASO's and RSO's ToS/PN as a contract of adhesion. (Also, presumably, the use of each RS comes at a time when Alice decided to use it, and the choice to sew together each RS with the AS – authorizing PAT issuance -- comes at an appropriate time also, so, the experience is at her discretion.) Our work to add to templated clause text can strengthen the provisions of these contracts even if there are several preceding the license phase. - Eve: In some deployment ecosystems, the ASO may be singular because other parties are aggregated into it (ASO + singular RSO, ASO + RSO + CO, etc.). In these cases, the process of accepting an initial (non-UMA) ToS/PN and authorizing a later PAT, e.g., could be rolled into one. - Jim and Kathleen: In some cases, Alice may have power, either because the RO is "AliceCo" (not directly in our framework's scope for now) or because the law gives her more power (e.g. "patient right of access") – effectively, the Alices have been "aggregated". These effectively give strength to the templating we can do. Jim: Regarding improving the circumstances of the "little" party wrt the "big" party, you can do it through influencing law (out of scope for our group), you can do it through intermediaries, you can do it through model terms/template clauses (the latter now being this group's favored phrase – so this would be our group's role in this ecosystem), and you can do it through adopting processes that enforce industry behavior that manage compliance risk for "big" parties (this is how others could use our deliverables – maybe IACCM, Pan-Canadian Trust Framework effort, other countries, other industries, etc.). We can't make anyone use this framework; rather, we want to make it as easy to use, adopt, adapt, and profile as possible. These links illustrate templating and ecosystem chains: http://www.commonaccord.org/index.php?action=source&file=Dx/Acme/09-EU-US-D… http://www.commonaccord.org/index.php?action=xEdit&file=G/TechContractsCom-… Eve has reached out to the people at Origo regarding their use of UMA (V1, however) and their potential need for ToC/PN that are protective of privacy rights in a standard way. https://pensionsdashboardproject.uk/saver/about-the-pensions-dashboard/ http://www.origo.com/news/Kenneth_May_Demonstrates_Delegated_Authority_Pens… https://www.ipe.com/countries/uk/uk-government-backs-pension-dashboard-proj… Let's plan to focus on this as a candidate case study/use case in the document. It has properties of strong authentication, a likely "design pattern" of sharing we'll see again, a government friend for Alice in negotiating the terms ("you and what army?" "this army!"), non-co-located services/parties, mappings to many of the characteristics of the use cases we gathered in deliverable #1, people who profiled UMA for real use already, etc. It only doesn't have UMA2, but we could work around that. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

17 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