- WG-UMA - mailman.kantarainitiative.org

FW: Authentication and Authorization for Research, and Collaboration 2: expressions of interest
by Keith Hazelton 15 Nov '15

15 Nov '15

The major authNZ initiative in EU at the moment, focusing on user-driven innovation. ________________ On 2015-11-15, 03:22, "David Groep" <davidg(a)nikhef.nl> wrote: >Dear FIM4R and parties interested in AAI for collaboration and research: > >As you are likely aware the Authentication and Authorization for Research >and Collaboration project AARC [aarc-project.eu] works towards an >integrated authentication and authorization infrastructure - built on >federated access - to enable users (using their existing credentials) to >seamlessly access e-infrastructures and support increased penetration >of federated access. Supporting actions include training and policies >and best practices harmonization. > >With this communication we would like to inform you about the plans >by the AARC Board and Project Partners to reply to the "User-driven >e-infrastructure innovation" call [1] by the EC, with a focus on >user-driven innovation and pilots on existing e-Infrastructures to >respond to user-community challenges > >You are requested to read the attached document and consider the >next steps detailed therein to help our researchers, educators and >students with an AAI that facilitates inter-federated usage >and sharing of resources. > > With kind regards, > Licia Florio, p.p. David Groep. > >[1] Please see >http://ec.europa.eu/research/participants/portal/desktop/en/opportunities/ >h2020/topics/2120-einfra-22-2016.html > >-- >David Groep > >** Nikhef, Dutch National Institute for Sub-atomic Physics,PDP/Grid group >** >** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL >**

1 0

Draft minutes of UMA Legal telecon 2015-11-13
by Adrian Gropper 13 Nov '15

13 Nov '15

Minutes Jim - GAGH (Global Alliance for Genetics and Health) - With machine readable consent group. Starting with taxonomy for access. Figure out a way of handling the specification of authorization of use of a genome. With Thomas working on a UMA / Common Accord / Blockchain hack. Scot interested in gene information sharing. Adrian also involved via a Mayo Clinic genomic determinism and data management. Steve with blockchain. Ann wants to help. Will be at FutureCommerce Hackathon. Thomas: CommonAccord for GitHub contract version tracking and specialization. The core contribution from Jim allows modularized pieces of the contract. Transacting parties A and B would each have to set up their own GitHub client and each time a party makes a change a hash is sent along with the diff that's sent to the other party and the hash is also put up on a blockchain. UMA comes in for the privacy aspects of the contract. Access control to contract via UMA to avoid having to ship the contract around. Consents expressed in CommonAccord format - points to data item - Organize the machine readable consent to drive UMA policies. CommonAccord + UMA + Blockchain is a general solution. Blockchain is advertising my signature / providing non-repudiation / for the process. Helps with escrow. SHA-1 to find data a la BitTorrent and SHA-256 are combined. May need to also conform to the Digital Signature Act using X509. Stock market analogy - stock certificates, then derivatives. Multi-channel verification of rights. What can we code to explain this? CommonAccord interacting in a GitHub like server + add the hash drop out - then add UMA and later blockchain. Patient consent or material transfer agreements. Jim demos NDA between two parties. Called Nameless. Common Accord + code to build something like a Merkle tree + post hash to blockchain as the minimum viable demo. Separate piece of this - what would be a taxonomy of access - by adding UMA - Dazza suggests the iAuth project for FutureCommerce that takes the hash of a commit in GitHub and its message digest via GitHub API (blocksign) - then make it so one of the commits are linked to OAuth2 / UMA and tied to a scope. Let's continue this discussion on 1 2 or 3 projects on the Slack channel for the next week as prep for http://futurecommerce.civics.com/index.html Please email Dazza or Mark to join the Slack channel (I don't seem to have invite power). Legal call next week will go on as scheduled and FutureCommerce starts an hour after (1PM EST). ----------- Proposed Agenda: - How can we reduce legal and business barriers to real-world UMA adoption? - What does the link between a minimal / personal UMA AS and Agency Law look like on GitHub? - FutureCommerce Hackathon at MIT and online next Friday - starts an hour after the end of our UMA Legal call http://futurecommerce.civics.com/index.html - AOB Roll call Attending Clayton Bonnell - USPS - Postal Inspection Service Steve John Jim Paul Thomas Ann Scot Sal Dazza -- Adrian Gropper MD <http://patientprivacyrights.org/donate-2/>

1 0

Reminder: UMA legal subgroup telecon 2015-11-13
by Adrian Gropper 13 Nov '15

13 Nov '15

- *Fri Nov 6* 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 - *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 - How can we reduce legal and business barriers to real-world UMA adoption? - What does the link between a minimal / personal UMA AS and Agency Law look like on GitHub? - FutureCommerce Hackathon at MIT and online next Friday - starts an hour after the end of our UMA Legal call http://futurecommerce.civics.com/index.html - AOB 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 -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

2 2

This will get more people talking about HEART
by Adrian Gropper 11 Nov '15

11 Nov '15

http://geekdoctor.blogspot.com/2015/11/the-path-forward-for-meaningful-use.… Halamka is arguably the chief spokesperson for the health IT industry. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

Gluu Blog: How to centrally issue OAuth tokens for API access management
by Mike Schwartz 09 Nov '15

09 Nov '15

Umatarians, I wrote a quick blog this afternoon about using UMA for API access management: http://www.gluu.co/central-oauth2-tokens Any comments are welcome if I messed it up or missed anything crucial. - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike(a)gluu.org

1 0

Notes from UMA legal subgroup telecon 2015-11-06
by Eve Maler 08 Nov '15

08 Nov '15

Fri Nov 6 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> Goal: start building a general "legal stack" for UMA-specific elements Learn more of Andrew H’s use case details Examine the sociotechnical norms for potentially useful concepts AOB Attending: Eve, John, Ann, Adrian, Andrew H, Jim, Jon, Mark, Nat, Sal Andrew has sketched a model for resource set registration services. So far this is very informal, so we won’t be minuting it in detail. What’s a better word/phrase for “community of interest”/CoI? Policymakers? Constituents? He’s trying to capture “reliance” relationships, and obligations/commitments. Adrian has concerns: Can we look at the simplest possible scenario and just map that? On the other hand, providing “legal resources” (akin to “developer resources”) for those who have constraints that require an UMA solution would be very valuable, because this is a real-world situation that we expect to be common. The “Open Identity Trust Framework Model <http://openidentityexchange.org/wp-content/uploads/the-open-identity-trust-…>” white paper may be useful for background on generic trust frameworks. OITF was influenced by the Liberty Alliance work, and Andrew has contributed to TF work heavily over time. Once you have the abstract model, then you can identify your specific “users” and “operators”. So can we make progress on our goal, given Andrew’s input? We could work on outputs for his “C” elements, and a lot of the “B”. Jurisdiction clauses are something everyone needs. And if we pick a business environment (university, or health, or DIACC!), we know of typical clauses they’ll need. UMA-specific stuff may affect, all of the business, legal, and technical sections (portions of the stack). Standardizing these clauses is the benefit we’re aiming to supply. Can we use the sociotechnical norms language <http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/IJCAI-15-TIST.pdf>? Eve suggests that the five norms are so clear, and clarifying, that they would be helpful for distinguishing the piece-parts of UMA flows that reflect different norms and developing model clauses for each of the B, L, and T layers that can focus on one type of norm at a time. John W thinks that there is relevance for consent receipts. Eve muses: Maybe Authorization could be for true consent receipts, and Commitment, Prohibition, Sanction, and Power could be for other types of transaction receipts? Powers could be conveyed to another party (such as durable medical power of attorney), and then there could be a flow chart after that where prohibitions and sanctions and such come into play. Next steps: Adrian is kindly running the next call. He will send out an agenda focusing on agency restatements. After her vacation, Eve will work with John and Andrew (and maybe rope in Tim as well?) on recasting whatever old Binding Obligations are still useful into norms language, and try to bucket them into B/L/T clauses for putative sections of a “stack". Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

8 8

FutureCommerce Hackathon & Symposium Event at MIT
by Adrian Gropper 07 Nov '15

07 Nov '15

Previews and Live Discussion: Monday, November 9th at 2:00pm Eastern via this page: http://futurecommerce.civics.com/index.html#whats-next <http://futurecommerce.civics.com/index.html#whats-next>FutureCommerce Hackathon & Symposium November 20-22, 2015 Online and In-Person Open Event *by* MIT Connection Science @ The Media Lab ------------------------------ The FutureCommerce Hackathon and Symposium is a creative event for team-based generation of innovative commercial products, services, transactions, experiences, relationships and business models. Enroll and/or propose a project at http://futurecommerce.civics.com/index.html --- Shameless plug: I will be proposing a GitHub project to create an open source reference implementation of a _personal_ UMA Authorization Server. The goal is to accelerate adoption of standard APIs for controlled access to the personal information that service providers have about us. The project is called HIE of One. It's not healthcare specific. Attend the Nov 9 preview and/or just connect with me directly if you would like to know more. -- Adrian <http://patientprivacyrights.org/donate-2/> <http://patientprivacyrights.org/donate-2/>

1 0

UMA testing / SecurityLoft / Client calls API
by Mike Schwartz 06 Nov '15

06 Nov '15

UMA-tarians, We've been talking about interop / conformance testing for a long time, and I think we need to get this to the starting line. There are a lot of UMA use cases that we need to prove out. I think we all agree that in order to move forward, we should start small, and in each iteration, cover more cases. This past IIW, I broached the idea of forming a new volunteer organization called "SecurityLoft". I have been inspired by OWASP. To start, SecurityLoft would just be a website, and a cloud server somewhere. I spoke with Kelly Grizzle at Sailpoint about hosting SCIM conformance tests at SecurityLoft. Perhaps SecurityLoft could also host UMA tests. The specific use case I think we should start with is (drum roll please...): Client calls API on Resource Server To get this done, we'll need to make a policy that any client can call to test positive and negative results. To make it easy to start with, I suggest using a policy based on time. In order to get a successful request, the permission ticket must be registered in the first 15 seconds of the minute. Just an idea... I was also thinking perhaps the UMA client could send claims as a json payload. Modest start? Yes! But at least a start that shows something tangible! - Mike

2 1

Reminder: UMA legal subgroup telecon 2015-11-06
by Eve Maler 05 Nov '15

05 Nov '15

Fri Nov 6 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> Goal: start building a general "legal stack" for UMA-specific elements Learn more of Andrew H’s use case details Examine the sociotechnical norms for potentially useful concepts AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Draft minutes of UMA telecon 2015-11-05
by Eve Maler 05 Nov '15

05 Nov '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05 Minutes Roll call Quorum was reached. Next week's calls The WG call and the APAC sync are cancelled. The legal subgroup call will be run (and an agenda sent) by Adrian. Eve will "split the difference" with APAC-friendly calls and schedule one for two weeks from now vs. next week and three weeks from now. Public Review and WG approval for LC certification as Draft Recommendations so that All Member Ballot can begin Joni reports that we got a fair amount media attention, but no comments through the KI channel. We got a couple of pull requests for minor typos (thanks, Sarah!) and Eve reported a few minor editorial issues and subsequently incorporated fixes for all but one. Maciej has generated drafts with all of that incorporated. MOTION: Andi moves and Mike seconds: Approve the UMA Core V1.0.1 and OAuth RSR V1.0.1 specifications dated 5 Nov 2015, as amended with the agreed resolution to issue #229 and appropriate document metadata, for LC certification as Draft Recommendations so that All Member Ballot can begin. APPROVED by unanimous consent. The Status section should say, instead of "...for Public Review", should say "for LC certification as a Draft Recommendation". AI: Maciej: Edit the specs so we can turn them over to the LC to take up their e-ballot. AI: Eve: Edit the Release Notes slightly to indicate the status change of the specs. Independent Submission stance: any news/changes? The discussion to gather more information is still ongoing. Permission registration extension spec review We discussed the configuration data situation. Do we want to have an official UMA configuration data property that contains an array of profiles and extensions supported (by identifying URI)? Or instead – or in addition – does it make sense to have a property for each profile and extension (as this spec proposes) where the name is the identifying URI, and then you could provides all kinds of values, or even arrays etc., for finer-grained configuration of each profile and extension? George proposes something like this: "extensions_support is a JSON map where the key name is the extension URI and the value is a JSON object defined by the extension" This would ideally be something baked into the UMA spec. Does it make sense to do this in "the first extension produced by the UMA WG"? Also, the line between profiles and extensions is kind of thin. The spec, in Core Sec 1.4, explicitly stays out of the business of capturing profile or extension config data (at the end of the section). Should we get into the business? We're thinking maybe not. The mere presence of the key might normally indicate that the AS supports the extension. However, in an ecosystem where there are multiple AS's, and some do support the extension and some don't, a random RS might want all AS's to explicitly declare the situation. So that's where a key of "identifying_URI" and a value of something like a Boolean could be used. If the extension in question wants to have the AS provide a complex set of parameters whenever they do support the extension, it would be ideal to allow the parser to be able to stop the moment it knows that the AS doesn't support the extension, vs. parsing a whole object. (Think token introspection.) For our purposes here, we can keep it simple. Let's change to a Boolean for now. AI: George: Write up a short UIG section capturing the above discussion on profile/extension config data. (Eve will send links and instructions.) For the question about registration failure, George recommends for the AS to return an array of resource set IDs, each with a status, with an overall error. Are we sure we want to return a single ticket for the set of requested permissions? The RS has always had complete discretion about what to register. However, since resource sets may have scopes that are totally distinct from each other, it may be very important – party for interoperability's sake – to explicitly register requested permissions for each resource set. Note that the RS's registration of requested permissions is just about a bundling on behalf of the client. We don't get into authorization questions until the client actually conveys the ticket back to the AS to ask for authorization data at the RPT endpoint. So we're talking syntactic errors at this point. We're agreed that if there's an error in the request, the whole request should fail. We seem to need more discussion about multiple requested permissions vs. one returned ticket; we know there would have to be a lot more infrastructure invented if we returned multiple tickets. AI: Eve: Rev the permission registration extension spec. IIW 21 roundup Sorry there was no time to talk about IIW impressions! Do see the notes here <http://iiw.idcommons.net/IIW_21_Notes> (more still to come). There were lots of amazing discussions about UMA, and also consent receipts, and blockchain. (And don't miss Beyonce as a Service!) Previous 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: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Andi and Zhanna: Please look at the section on optional and extension properties to see what might need an update to account for V1.0.1. [DONE] AI: Maciej: Review and correct the Redirecting the Requesting Party to the Client After Claims Gathering section. AI: Maciej: Write up some recommendations for the RPT Refreshing section. AI: Maciej: Try to find Justin's old recommendations for the Permission Ticket Management section. Attendees As of 13 Oct 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Mary, Robert, Maciej, Eve, Sourav, Lisa, Arlene, Mike) Eve Andi Arlene Thomas Domenico Mike Maciej Non-voting participants: James Adrian Harvey Nusz - attended IIW 21 last week - IAM and now privacy Sarah Andrew J Katie George John W Jin Guests: Joni Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0