- WG-UMA - mailman.kantarainitiative.org

Reminder: UMA legal subgroup telecon 2015-09-04
by Eve Maler 03 Sep '15

03 Sep '15

Fri Sep 4 8-9am PT Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Many thanks to Dazza for his ministrations last week! What a team. We are unstoppable. We only had Jon, Adrian, and myself as “legal subgroup regulars” on today’s WG call, so the following is an agenda but also a lot of context-setting... An important topic came up that relates directly to our work here: the “wormhole” between the UMA Core spec and our ultimate deliverables, connecting “technical" to “legal”. There were two key wording changes: #1: From this: "If the client's request at the protected resource has a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client, it MUST give access to the desired resource.” to this: "The client's presentation of a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.6) indicates that the resource owner's policies have been met. The resource server MAY apply additional authorization controls when determining how to respond." #2: From this: "The resource server MUST NOT give access where the token's status is not associated with sufficient authorization data for the attempted scope of access.” to this: "The resource server must not give access in the case of an invalid RPT or an RPT associated with insufficient authorization. To ensure the integrity of the ecosystem in which the resource server, authorization server, and resource owner are participating, it is STRONGLY RECOMMENDED for the parties to establish agreements about access rules in this case on a legal or contractual level. See Profiles and Trust Establishment for more information." These both relate, essentially, to the RS’s natural reluctance to do what the AS/RO tell it to do. UMA’s entire purpose is to enable outsourcing of protection of resources. But UMA can’t actually make the RS do the protocol’s bidding if the RS has interests that aren’t well aligned with the others’. Don’t forget this, in the intro section: Practical control of access among loosely coupled parties requires more than just messaging protocols. This specification defines only the "technical contract" between UMA-conforming entities. Work is ongoing to define recommendations for developing agreements about the rights and responsibilities of parties operating and using these entities on a contractual or legal level (see, for example, [UMA-obligations]). Parties operating entities that claim to be UMA-conforming should provide documentation of any rights and obligations between and among them, especially as they pertain to the concepts and clauses discussed in this companion specification." It’s valuable to read the above in combination with Adrian’s new analysis of the Restatement of Agency <https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS…>, which also includes notes from the both of us on deltas between UMA’s technical layer and what’s desired. Tomorrow, let’s tackle the items identified last week as our next steps, colored by the above: It was confirmed that the group should continue working through the HIPAA use cases As part of this, confirm/correct the non-experts’ analysis <https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS…> of the Restatement of Agency ...and review the “technical UMA healthcare safe harbor propositions” …on the assumption that these activities will be broadly valuable/applicable (based on the WG call’s discussion) It was evident participants want to further discuss the Apple Healthkit/Researchkit and so it will be included as a variation of the initial health information scenarios. Dazza will work with Adrian (and anyone else so inclided) to refactor the use case table scenarios into more detailed cross-functional process diagrams (aka swim lane diagrams) including agency law overlay (and possibly a first guess as to where contracts are formed, already exist or could be monkeyed with). When ready, a link to the diagrams in the wiki will be emailed to the list for everybody to hammer at or at least view them. Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Draft minutes of UMA telecon 2015-09-03
by Eve Maler 03 Sep '15

03 Sep '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-03 Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the minutes of UMA telecon 2015-08-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27>. APPROVED by unanimous consent. Conclude on topic: GitHub paradigm Plan of record: Use GitHub tricks to clean up our IP hygiene; keep the repo open. AI: Eve: Convey GitHub best practice lessons learned to Sal for LC knowledge. Spec review work in preparation for 45-day public review #15: Adrian would like to see the RS register its intent with the AS, in order to inform the RO, to act contrary to the sufficiency-of-authorization indications associated with the RPT presented by the client. The "The resource server MUST NOT give access where the token's status is not associated with sufficient authorization data for the attempted scope of access." wording was meant to be a "wormhole" into the Binding Obs or other legal subgroup outputs, because it's not technically a testable assertion. We changed the MUST NOT to a STRONGLY RECOMMENDED wording. AI: Adrian: Submit an issue to solve the "RS notifies RO of access" challenge. The rest of the items just need careful review by everybody. AI: EVERYONE!: Please review the specs (which Eve will republish today) carefully by Monday, and put any new issues in GitHub. AI: ALL VOTING PARTICIPANTS: Please attend next week's meeting to achieve quorum. UIG status Deferred. AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. [DONE – thank you, Sal!] AI: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Maciej: Write as many sections for the UIG as he can. AI: Justin: Write a UIG section on default-deny and race conditions. Attendees As of 1 Sep 2015, quorum is 7 of 12. <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> (François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Arlene, Irwin, Mike, Jon) Eve François Domenico Sal Robert Mike Jon Neiditz - legal subgroup member Maciej Non-voting participants: Sarah Mark Adrian James Justin George Colin Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

for those who need the link -
by Dazza Greenwood 03 Sep '15

03 Sep '15

The legal subgroup is reviewing use cases now here: https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Role… Also, we are walking through some healthcare wrinkles that Adrian contributed, here: https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNL… Thanks, - Dazza _ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _

5 8

Re: [WG-UMA] [wg-uma] What deliverables should the UMA Legal subgroup provide? (#180)
by Adrian Gropper 03 Sep '15

03 Sep '15

I think the most important deliverable is a clear explanation and demonstration of how implementing UMA will provide the Resource Server institution increased cybersecurity and a safe harbor for exposing an interface to the public Internet. Although many of us are mostly motivated by other goals including consumer protection and the hope of selling software to the operators of authorization servers, these will not drive adoption of UMA without new laws and regulations. Let's see how far we can get with the current laws. To this end, Dazza has provided a wonderful document about Restatement of Agency Law <https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformAct…>. I've tried to map the essential elements of Agency: Principal, Agent, and Third Party into a very simple document https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS… that is open for discussion and editing. Eve and I had a very long session trying to understand the gaps between the Agency Law and UMA. These gaps are represented in the table toward the end of the Gdocument. I think that mapping UMA to Agency Law is more important and easier than standardizing or formalizing Terms of Use and Privacy Policies. To the extent that we can map UMA to Agency Law without introducing any specific profiling for healthcare, education, or any other vertical domain, we will be doing the best job of promoting adoption of UMA for the benefit of the RSs, the ROs, and the AS business. Adrian On Wed, Sep 2, 2015 at 1:11 PM, Dazza Greenwood <notifications(a)github.com> wrote: > In conversations during the Legal subgroup meetings, some people have > suggested including example, sample or "standard" legal wording for ToS and > other legal instruments for use with UMA deployments. Not yet sure what > those would say, but it would be a sign of success to get to the point of > recommending such terms. If the subgroup deliverables includes both > recommended terms and an approach to audit logs for legal compliance or > enforceability, we would have a strong set of deliverables. > > — > Reply to this email directly or view it on GitHub > <https://github.com/KantaraInitiative/wg-uma/issues/180#issuecomment-1371747…> > . > -- Adrian Gropper MD RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

4 4

Re: [WG-UMA] Handling spec writing process @ GitHub [+legal]
by Dazza Greenwood 03 Sep '15

03 Sep '15

As promised, here is a primer specifically for UMA on how to use open GitHub repositories for open standards work while proportionally managing the need to avoid or deflect proprietary and other inappropriate contributions. The concern about GitHub issues potentially introducing unacceptable IP into the workgroup content pipeline is addressed by projects on GitHub in a few ways. The main thing is what Justin said: use a LICENSE.md file in the main project repository root directory and that is generally agreed to apply to all the content in the repo unless otherwise indicated. However, this may be too loose for some projects. To provide even more tools for managing the risks of inappropriate or unacceptable contributions, GitHub directly supports workflow and event trigger solutions to ensure appropriate notices. To trigger an automatic notice to all users who submit an issue in our repo, I recommend adding a CONTRIBUTING file (CONTRIBUTING.md). If a repo has a file with this name, then whenever someone opens a pull request or creates an issue, they will see a link to that file. A good example is: https://github.com/opengovernment/opengovernment/blob/master/CONTRIBUTING.md The GitHub documentation is here: https://help.github.com/articles/setting-guidelines-for-repository-contribu… I have created a starting file for our repository and submitted a pull request here: https://github.com/KantaraInitiative/wg-uma/pull/186 The CONTRIBUTING.md file just needs to be anywhere in the root of your project's repository, where one expects to see a README and LICENSE file. This is one of the basic practices that makes participation and contribution to a variety of projects in GitHub quick, easy and effective. The standard practice enables anybody to quickly scan a few key files and get a sense of the project landscape. The very tightest method to lock down contributor IP assignment is an affirmative signed agreement to terms. I'm speaking with GitHub people about legal projects operating on their site and ask what they think about adding a function enabling Repo owners to require an affirmative assent to the LICENSE file in order to make a pull request or submit an issue (eg a check box creating a logged event associating the user account with the action and the then current files at the time of the action). For the UMA GitHub repository, at this point requiring an affirmative consent to our open IP terms seems like overkill. Especially given it is our choice whether to accept and incorporate material submitted via issues into our work. Using GitHub is a very very good way to open up to a larger world of collaborators and implementers and others and it is a powerful way for teams to collaborate internally and with partner teams/projects. Closing the repo to prevent contribution of issues would be disproportional to the risk and would signal a less open style. Given Kantara membership for contributors is free and depends on voluntary allocation of time and donation of IP, a culture of inviting participation rather than dampening it would be the best fit. The best GitHub projects (and the best open projects I am familiar with) embrace using issues for the general public to ask questions and sometime for other innovative and very beneficial solicitations of feedback/public review and other innovative uses. The current best practice of presenting a notice at the top of the submission box is appropriate and well used by GitHub projects of all sizes and types. Thanks, - Dazza PS: I just noticed we actually don't have a standard LICENSE.md file in our repo. Not good. I created a Pull request for that too, here: https://github.com/KantaraInitiative/wg-uma/pull/187 The wording of the LICENSE.md file I threw together should probably be further crafted, but it inludes links to the Kantara source license materials and it should be good enough to get this on the map and start garnering the benefits of this standard practice for identifying the license terms applicable to content in GitHub repositories. Some discussion of license wording is needed (eg whether to copy/paste the Kantara license into a GitHub LICENSE.md file or to use the LICENSE.md file to point people to the Kantara IP pages). _ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _ On Wed, Sep 2, 2015 at 10:47 AM, Dazza Greenwood <dazza(a)civics.com> wrote: > What Justin said should reasonably suffice but to add more IP protection GitHub > can produce an automatic notice to all issue submitters. We just need a How > to Contribute to the Repo file to trigger this feature. I'll post a link in > a few minutes to show how and provide example organizations that do this > practice. > > | Sent from my iPhone > | Please Forgive Typos > _________________ > | Dazza Greenwood, JD > | CIVICS.com <http://civics.com/>, Founder & Principal > | MIT Media Lab, Visiting Scientist > | Vmail: 617.500.3644 > | Email: dazza(a)CIVICS.com > | Biz: http://CIVICS.com > | MIT: https://law.MIT.edu <https://law.mit.edu/> > | Me: DazzaGreenwood.com <http://dazzagreenwood.com/> > | Twitter: @DazzaGreenwood > | Google+: google.com/+DazzaGreenwood > | LinkedIn: linkedin.com/in/DazzaGreenwood > | GitHub: github.com/DazzaGreenwood/Interface > > On Sep 2, 2015, at 10:40 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: > > This is great input. Dazza also aligned with transparency generically in > his previous note; now that we’ve brought up the IP regime specifically, it > would be good to see if the DoLs (disputation of lawyers) as a whole have > additional thoughts. I’ve flagged the topic in the subject line. > > We do have a README with an IP health warning now, seen here… > > https://github.com/KantaraInitiative/wg-uma > > Perhaps you and Maciej and I can take this offline, but I see that COSE > decided to have separate repositories in order to get …/cose-issues. Since > the wg-uma repository currently sits under …/KantaraInitiative, I wonder > what’s a good way to put the warning in front of people when they hit the > issues landing page. > > Eve > > On 2 Sep 2015, at 7:18 AM, Justin Richer <jricher(a)mit.edu> wrote: > > I would strongly recommend *against* closing the issue tracker. If you had > done so before, I wouldn’t have been able to submit *any* of the issues > that I had. Don’t stand in the way of well meaning people who want to make > contributions. :) > > I’m not a lawyer, but I’ve dealt with this in other venues. In software, > generally, reported issues in a public tracker like this are considered > contributions, and not all contributions covered by whatever licensing the > codebase has. And since the issues do not directly affect the codebase > (even pull requests) but have to go through a core contributor’s hands, > there’s a gating system built in. You can also put a notice to this effect > (like the IETF Note Well or a software project’s LICENSE file) in the main > project that the issue tracker is attached to. We’re doing something like > this with COSE: > > https://github.com/cose-wg/cose-issues/ > > Basically, it’s a contract-of-adhesion kind of thing, where if you > contribute you’re agreeing to IPR associated with it, without signing > anything. Now if only we had consent receipts or something that could > generate from this transaction... > > — Justin > > On Sep 2, 2015, at 12:07 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: > > Oh sorry, you did address closing the repo. I think we can only execute on > “Only primary editors should have write access to the repository and should > be allowed to make changes directly to it” if we do that, and it will have > the same effect on the issues, iirc. > > Eve > > On 1 Sep 2015, at 9:05 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: > > This makes sense to me. I think James brought up using branches for > everything just because he’s involved in insanely large projects. :-) > > We didn’t actually conclude our discussion of whether to “close” the repo > in order to look after IP hygiene, but it sort of relates to this topic. > (Though pull requests from random non-participant strangers can always be > put aside; it’s more the issue discussions that we were asking about). > > Eve > > On 1 Sep 2015, at 7:24 PM, Justin Richer <jricher(a)mit.edu> wrote: > > The overhead associated with fully distributed development when there is a > clear core team is not worth the headaches it can cause, especially since > nobody that I can see would be taking the job of patch integrator to manage > all the pull requests. Having an editor create a pull request and then > merge it themselves into the main repository is just a waste of that > editor’s time. > > Only primary editors should have write access to the repository and should > be allowed to make changes directly to it. Things that are WG consensus > should go on “master” (or the appropriate version-tracked major branch), > proposed solutions and text by the primary editors should go on branches in > the main repository and brought to the group for feedback. > > Non-editors (like myself) can fork the repository, branch, and create > either pull requests or simply reference commits and issues from there. > > — Justin > > On Sep 1, 2015, at 10:14 PM, Maciej Machulak <maciej.machulak(a)gmail.com> > wrote: > > Hi all, > > I refer to my earlier email - any comments? :-) Thanks! > > Maciej > > On 27 August 2015 at 22:39, Maciej Machulak <maciej.machulak(a)gmail.com> > wrote: > >> Hi, >> >> It was discussed today how the current process of spec editing looks like >> on GitHub (currently the spec is here: >> https://github.com/KantaraInitiative/wg-uma) All the changes are done >> on this repository, some via branches and some directly to the master >> branch. It was suggested that maybe we could use distributed repos (each >> editor would have a fork of the repo) and changes to the main repo would be >> done via pull requests. >> >> While I agree that using pull requests is best practice, I think we could >> do without this for UMA spec editing. The current setup which we have is >> pretty low overhead and sufficient for our needs (we could probably improve >> on using branches but that's also not something we have to strictly stick >> to). >> >> However, I'd like to hear the opinion of others. Let me know so that we >> can act accordingly. >> >> Maciej >> >> -- >> Maciej Machulak >> email: maciej.machulak(a)gmail.com >> mobile: +44 7999 606 767 (UK) >> mobile: +48 602 45 31 66 (PL) >> > > > > -- > Maciej Machulak > email: maciej.machulak(a)gmail.com > mobile: +44 7999 606 767 (UK) > mobile: +48 602 45 31 66 (PL) > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > > > > Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | > Calendar: xmlgrrl(a)gmail.com > > > > Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | > Calendar: xmlgrrl(a)gmail.com > > > > > Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | > Calendar: xmlgrrl(a)gmail.com > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > >

4 3

Notes from APAC-friendly UMA WG sync 2015-09-02
by Eve Maler 03 Sep '15

03 Sep '15

Attending: Eve, Paul, Allan Agenda bashing: - Looking at UMA in the context of sport (Australian Digital Transformation Office has an interest) There are similarities to health, and there are customer relationships as well. An under-6 soccer game involves two teams, two clubs, a competition organizer, a venue manager, and a referees’ organization. There are different legal entities, and a lot of personal data flying between them. This is what makes it a little similar to health. “Children checks” involves officials who are members of sport organizations that cross state-level jurisdictions. And a lot of people involved are volunteers. If a dad is a volunteer coach, he still has to go through the check. If one person is a coach for two different teams/kids/sports, the person may have to go through the check multiple times. Paper forms are often still involved in this world. There are also sport associations at local, state, national, and international levels, responsible for different parts of the process. The vision would be, e.g., that a volunteer coach could go through a single check and have it be valid for other activities as long as it’s fresh enough. Along with underage child regulations, there are also anti-doping regulations to think about. There’s an interest in trust frameworks around this. What’s the relationship between UMA trust framework opportunities and the Kantara and OIX work on trust frameworks and the UMA legal subgroup work? The Kantara trust framework came out of the US FICAM and NIST SP 800-63 material, but is not US-specific. Kantara has approved assessors that approve organizations under that trust framework. A key motivation for doing this is actual FICAM acceptance, which is valuable for (likely) being accepted sight unseen by the US General Services Administration. There’s work ongoing to map US and UK trust frameworks. OIX runs a registry that can hold registrations, for communities of interest that have a trust framework, of members in good standing in that framework. Right now it only holds one set of entries, for a technical-level community run by OpenID Foundation recording self-certified conformance to the specs. So Kantara sort of specializes in “config-time” and OIX sort of specializes in “run-time”. Some other identity federations in higher education and research have their own trust frameworks. What is the UMA legal subgroup doing? The mission of record is: "Develop recommendations about resource owner-and-requesting party [Alice-and-Bob], resource server-and-authorization server [service-and-hub], and any other transactional relationships in the UMA environment, keeping in mind international jurisdictional friendliness; applicability to many different vertical and horizontal use cases, including health; and support of higher-level access federation trust frameworks and similar efforts.” The parallels between health and sport are actually pretty strong, as long as we stay away from only government, only health, only US, etc. One difference is that the people and even some of the organizations involved are at a small, non- or under-funded scale. It’s mom-and-pop a lot of times, and volunteers can’t deploy IT infrastructure. AI: Paul: Follow up on these notes with some specifics on “legal use cases” that arise out of the sport scenario. Who would be the Principal of interest in each? Etc. - V1.0.1 status update? We should close the specs for 45-day public review as of next Thursday or earlier. That would mean it’s effectively stable at that point, modulo public review period comments. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 3

Agenda for UMA telecon 2015-09-03 (starting at traditional time once again)
by Eve Maler 02 Sep '15

02 Sep '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-03 Date and Time Thu Sep 3, 9-10am PT (we revert to our original starting time of 9am PT starting in September!) Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Agenda Roll call Minutes approval Sample motion: Approve the minutes of UMA telecon 2015-08-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27>. Last-minute quick hits Conclude on topic: GitHub paradigm Sal's IDESG form for UMA as "recommended standard" Spec review work in preparation for 45-day public review Specs for review and email thread with some open issues here <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/_97OoYDlt…> Issues on GitHub here <https://github.com/xmlgrrl/UMA-Specifications/issues> Timeline for patch release process here <https://docs.google.com/document/d/1c50top8X6Aqw3CEVeX_SD2THqO508ihs14QwLem…> What is the likelihood of our reaching quorum next week? If time: UIG status AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Handling spec writing process @ GitHub
by Maciej Machulak 02 Sep '15

02 Sep '15

Hi, It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma) All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests. While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to). However, I'd like to hear the opinion of others. Let me know so that we can act accordingly. Maciej -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

4 8

Associating the Requesting Party/Authorization client with the permission ticket.
by Farazath Ahamed 02 Sep '15

02 Sep '15

Hi, First of all thanks everyone for helping me out in this mailing list answering my questions that helped me a lot in getting through my GSoC. However, I am yet to complete my implementation. Therefore i will keep on pestering you with questions :) Getting to the question, We use the PAT to register permissions using the Permission Registration endpoint of the Protection API, do we have a standard way of associating the client who requests for access from the UMA protected resource server? Thanks -- *A.Farasath Ahamed* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath(a)gmail.com

3 3

Drafts of Core and RSR specs for your immediate review
by Eve Maler 02 Sep '15

02 Sep '15

I have attached HTML versions of the specs for you review. (I’m not posting them on the site, so that nobody gets the idea they’re finished/vetted.) Many thanks to Maciej for working on a fresh Kantara-specific XSLT transformation! His work isn’t complete, so there are a few formatting/front page things yet to do; don’t worry about those. Everybody please review these formatted specs carefully for ALL the issues you care about, and report any new issues in GitHub <https://github.com/KantaraInitiative/wg-uma/issues> Or feel free to send notes to the list or to me privately if you like, and I can collate them. We will discuss everything this Thursday. I think we should probably take the time to continue our review through to Sep 10 if we feel at all rushed, or want to see complete new renditions. This is because, once we exit the 45-day Public Review period, we can no longer make technical changes without going back to square 1. We should be quite sure we’re happy with these drafts when they go into review. (Luckily, I no longer have a conflict with our Sep 10 meeting.) Here are some items that we already know need editing, discussion, or review: Don’t forget that there is new wording for permission ticket lifecycle management as discussed last week, which needs your review. See Core Sec 3.2.2. Our new wording in response to #161, Protocol assumes one resource owner per URL <https://github.com/KantaraInitiative/wg-uma/issues/161>, says “When a client attempts access to a presumptively protected resource without an RPT,...”. This appears one place in RSR, where I changed “an RPT” to “an access token” and added an [UMA] cross-reference. But in the Core spec, should it say “an access token” generically? Maciej and I discussed some questions he had around the RSR security considerations, in RSR Sec 4. What does a “valid web page” (a phrase that came from OAuth’s version) mean? I also recently added a new issue #185, RSR user_access_policy_uri: security considerations <https://github.com/KantaraInitiative/wg-uma/issues/185>, that may have us tweak that section a little further if we think it has merit. I actually implemented issue #179, Use OIDC specification style of providing a subsection for every type of response <https://github.com/KantaraInitiative/wg-uma/issues/179> and restructured Core so that every request and response has its own subsection — couldn't resist. :-) Of course, this meant major structural changes! Mostly I rearranged existing text, but I did end up having to rewrite section introductions and invent new introductions. And because Section 3 has a flow to it, I redid how the “flow chart” feel of the entire section works. Now the organization is a bit flatter (there is one bug I’d like to fix, which is that Core Sec 3.3-3.5 should actually be subsections in a single Sec 3.3), and each main subsection contains a consistent “how you got here” intro (and no outro). E.g.: “If the client's request at the protected resource has no RPT, or an invalid RPT or insufficient authorization data associated with the RPT as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client,…” Thanks in advance, all, for your review and attention. Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 5