- WG-UMA - mailman.kantarainitiative.org

New [legal] wiki pages with mappings to Agency law etc.
by Eve Maler 10 Sep '15

10 Sep '15

I know there are several legal subgroup folks intending to catch up after the long weekend, and jump in next Friday. Here are some resources that should help you: - GitHub wiki home page (see links off to the right for all the “UMA-Legal” pages): https://github.com/KantaraInitiative/wg-uma/wiki - Summary of special UMA terminology: https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Terminology - Proposals for mapping UMA (and OAuth) to Agency law (needs much review and vetting!): https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Mapping-Between… Please feel free to float any questions here. Happy Labor Day to those who are celebrating it! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

4 14

Draft minutes of UMA telecon 2015-09-10 (no meeting next week)
by Eve Maler 10 Sep '15

10 Sep '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-10> Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the minutes of UMA telecon 2015-09-03 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-03>. APPROVED by unanimous consent. Issue #205 Since the client already has to pass a state parameter, that can carry the burden of the ticket state anyway and enable the client to be stateless if it wants to be. It's good practice for the client to bind up the ticket into encrypted form in the state. Options: Stand pat: Keep the AS requirement and change nothing else Keep the AS requirement and encourage the client to check it ("MAY") - Justin Keep the AS requirement and encourage the client to ignore it Soften the AS requirement, making it optional ("MAY"), and encourage the client to ignore it – and indicate that we intend to remove it in a later release - George, Mike, Maciej, Andi Remove it from the AS's response – not backwards compatible Editorial instruction: Change to option #4 in the spec. Issue #225 Mike and Justin have reviewed and are okay with it. We're fine. Editorial instruction: Add "client's" to "the...request" at the end. Issue #207 Editorial instruction: Instead of "Errors can occur at the OAuth level and the UMA level.", say "Both OAuth and UMA errors can occur.", and check for "level" throughout. Issue #185 George and Mike are good with it. We're fine. Issue #198 Formatting will be taken care of! Thanks, Maciej! Claims-awareness as a concept Claims-redirect-uri should be registered not just if client is claims-unaware, but if it anticipates being untrusted or needing to redirect rqp ever (appears multiple times) Mention claims-unawareness and also untrustworthiness etc. in claims-redirect section? Tiny editorial things Smart quotes, UMA-configuration file path and https: mention need spanx, Add period to IPR statements in stylesheet, Sort Core references, Remove this from 3.5.4.2: An example of the use of these properties appears in Section 3.5.4, if we approve the docs for Public Review: change Status of This Document section and appropriate other metadata. Editorial instruction: Excise claims-awareness and claims-unawareness language from the spec. Consider approval of specs for 45-day Public Review MOTION: Andi moves and Maciej seconds: Approve of the Core and RSR specs of 2015-09-09, as amended according to the instructions of UMA telecon 2015-09-10, for progression to 45-day Public Review. APPROVED by unanimous consent. AI: Eve: Work with Jane C and the Kantara staff on the review process. Discuss and consider approval of IETF I-D publication Could be confusing to people as to what the canonical specification is. If we let the current I-Ds expire on October 6, then they have to come to Kantara for the latest specs. On the other hand, having the UMA specs on the IETF site helps with marketing. Mike's experience with the Open Interconnect Consortium showed this. No conclusion for now! UIG Can we press forward on this? Arlene can be one of our test readers. Katie and Andi offer help. Logistics Let's not meet next Thursday. Upcoming meetings will have a theme of interop testing. 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: 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 10 Sep 2015 (pre-meeting), quorum is 6 of 11. (François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Arlene, Mike, Jon) Eve Domenico Arlene Maciej Mike Andi Sal Non-voting participants: Adrian Ishan Justin Sarah George Katie Scott Colin Regrets: James Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com>

1 1

[Legal] Giving resource servers risk mitigation tools they're comfortable with, in/next to UMA
by Eve Maler 10 Sep '15

10 Sep '15

On our last subgroup call, Adrian and I agreed to do an exercise next time called “Adrian and Eve walk through attempted UMA mapping to Agency”. I thought it might be a good idea to explain in email ahead of time what the whole exercise is about. First, please note that in updating the GitHub wiki, I included a new page <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Mapping-Between…> that has OAuth agency-mapping work we completed on the last subgroup call. If you take a look at just the first section of this page, you’ll see the basic idea: choosing a perspective and literally mapping OAuth entities and flows to principal/agent/third party distinctions. Later in that doc you’ll see the “UMA mapping to agency” work that Adrian originally conducted, along with notes from me. Before reading on, though, it’s important to have more context. My perspective going in was: The UMA protocol today only has XYZ capabilities of expression, and no more. What I was hearing in Adrian's discussion of “an RS needs a safe harbor” was a variety of ideas about things that that sounded protocol-ish, but that I was concerned weren’t part of UMA today. So I was looking for a punch list of “technical things that still need to be developed” so that we didn’t over-promise anything. Adrian’s perspective going in was: Any operator of a service (i.e., a potential RS) that is worried about liability in handing out an individual’s data has got to protect itself, and the obvious expedient for protecting oneself is right in front of us: The example of a Release of Information (ROI) form used by healthcare providers, such as hospitals, in the US. Since healthcare is the hardest case known to humankind, and resource server operators have it the worst among all the UMA-related parties, and (I’m reading into things here) the liability situation for providers who release data is harsh in the US, if we can simply tack on the essential elements of the ROI form design pattern to UMA so that all RS’s in any vertical or sector can get the benefit (while also looking out for Alice), we’re golden. Below is a very old graphic (which can be seen in a predecessor document to the Binding Obs, the Legal Considerations in UMA Authorization <http://kantarainitiative.org/confluence/display/uma/Legal+Considerations+in…>) that helps visualize the challenge. Please forgive incorrect terminology (though it occurs to me that maybe we can leverage this graphical style in conveying our Agency mappings at some point??). Just focus on the “TOS” to the left of “Host Service Vendor” (which means “RS Operator”). That agreement is basically where the ROI form slots in, at least for hospitals, and it has outsized importance because it is the main contractual device that RS Operators use to manage their liability around personal data release. Now, because we want to be looking out for Alice, it’s not enough to just think about the RS’s needs. “TOS” would normally be take-it-or-leave-it Term of Service. Could UMA do better? This is where Adrian (with his infinite faith in UMA and technology!) had dreamed up an idea for what UMA really should offer, to go beyond just the “BL” world and into the “T” world. You can see the result of our discussion (about how UMA doesn’t currently satisfy such needs) in this new GitHub issue, #224, RS Notifies AS or RO of Access <https://github.com/KantaraInitiative/wg-uma/issues/224>. Even without any technical changes to the UMA protocol, we did recently make explicit room for the RS risk mitigation world with spec wording (what I recently called “wormholes” in email) that now reads <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1-2015-09-09.htm…> as follows (emphasis added): “The client's presentation of a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.4) indicates that the resource owner's policies have been met for access to the protected resource. The resource server MAY apply additional authorization controls when determining how to respond. …. 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 RECOMMENDED for the parties to establish agreements about access rules in this case on a legal or contractual level. See Section 7.4 for more information." Now, if you read the Proposal for Mapping UMA to Agency Law <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Mapping-Between…> section of the wiki page, you can see what Adrian was aiming at in his analysis, and we can judge its accuracy and suitability together on that basis. (My one request is that if we come up with cool things UMA could do that it doesn’t do at present, they have to go into GitHub as issues! :-) ) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 1

Specs -- please review for tomorrow -- see below for specific review items!
by Eve Maler 09 Sep '15

09 Sep '15

Hi all— Please find linked below the edited specs that take into account all the decisions, edits, comments, etc. of the last stretch: Core 2015-09-09 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1-2015-09-09.html> RSR 2015-09-09 <https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1-2015…> There are very few <https://github.com/KantaraInitiative/wg-uma/issues?q=is:open+is:issue+label…> issues that are still outstanding. Please note them well, and review where necessary so that we can be prepared to make decisions expeditiously tomorrow: 205, Potential ticket injection attack? <https://github.com/KantaraInitiative/wg-uma/issues/205> This is the one issue that remains undecided! Let’s kill this one :-) 225, Confusing reference to RPT in Protection API context <https://github.com/KantaraInitiative/wg-uma/issues/225>: Important: Per Tuesday’s meeting, I custom-crafted new language <https://github.com/KantaraInitiative/wg-uma/commit/4648853b9db634f65320cc46…> for our old “presumptively protected resource” Note in all Core locations, so please review this! 207, Incorrect OAuth error responses <https://github.com/KantaraInitiative/wg-uma/issues/207>: This section needed a reboot due to inaccuracy, so I gave it one <https://github.com/KantaraInitiative/wg-uma/commit/41f96889d74eb052e16bc3ea…>; please check 191, Expand terminology section <https://github.com/KantaraInitiative/wg-uma/issues/191>: I executed on this issue of Justin’s, and just wanted people to check out the wording <https://github.com/KantaraInitiative/wg-uma/commit/0d10eb2ca39a8e6fd78a3fbb…> 185, RSR user_access_policy_uri: security considerations? <https://github.com/KantaraInitiative/wg-uma/issues/185> Per Tuesday’s meeting, I have added wording <https://github.com/KantaraInitiative/wg-uma/commit/ab2219b510f65c6f447a1c8f…>; it needs review 198, XSLT verb rendering <https://github.com/KantaraInitiative/wg-uma/issues/198>: No decision needed; we’re still working on a few bugs (funny characters; need TOCs; let us know anything else) I also did some further editorial reorganization, and quite a lot of parts of the specs have gotten “touched” since last time, so quick page-by-page reviews won’t go amiss if you have a free hour before tomorrow. Don’t forget you can always flip through the newly committed text by-issue on GitHub. Thanks all, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Agenda for UMA telecon 2015-09-10
by Eve Maler 09 Sep '15

09 Sep '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-10> Date and Time Thu Sep 10, 9-10am 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 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-09-03 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-03>. Discuss any outstanding spec issues Consider approval of specs for 45-day Public Review Discuss and consider approval of IETF I-D publication If time, discuss Independent Submission plans If time, discuss UIG AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from ad hoc UMA telecon 2015-09-08
by Eve Maler 08 Sep '15

08 Sep '15

Attending: Eve, Andi, Thomas, Domenico, Mike, Sal, Maciej; Justin by back channel (thanks to all!) Non-editorial issues that have tentative solutions: https://github.com/KantaraInitiative/wg-uma/issues/206 We have rough consensus that one base64url encoding is enough! Anyone who thought otherwise would need to go and fix their V1.0 implementation. https://github.com/KantaraInitiative/wg-uma/issues/210 Removed the STRONGLY from RECOMMENDED — okay. Editorial issues with non-obvious solutions: https://github.com/KantaraInitiative/wg-uma/issues/144 The changes would, we feel, convince a quick reader used to OAuth spec reading that this redirection URI is something distinct! https://github.com/KantaraInitiative/wg-uma/issues/194 Discussion: Is it proper to REQUIRE default-deny? Would adding “registered” to “resource set” sufficiently tweak Justin’s wording? Since saying anything about default-deny is perpetuating a certain trust model, and doesn’t tackle technical interop. However, in a wide ecosystem use case, Alice will tend to expect default-deny, and would be very disappointed if default-allow were the behavior. So maybe this comes down to our “…all parties need to document expected behaviors” language. Mike can see some fairly likely cases of default-permit in his environment. We do want to be sure it’s a conscious decision of the deployment and not a result of poor implementation. We concluded that default-deny on the AS side really does need to be required to give UMA as many teeth as possible. Do we want to give this one example of a corner case? We have to assume there are others. Let’s shunt the entire discussion that is implementation-specific to the UIG. “The authorization server MUST use a default-deny authorization assessment model in adding authorization data to RPTs, that is, “everything that is not expressly allowed is forbidden” for resource sets that resource servers have registered. Exercise caution in implementing default-deny because corner cases can inadvertently result in default-permit behavior; see [UMA-Impl] for further discussion.” Justin would like to add the specific corner case back. Would this work, then? “The authorization server MUST use a default-deny authorization assessment model in adding authorization data to RPTs, that is, “everything that is not expressly allowed is forbidden” for resource sets that resource servers have registered. Exercise caution in implementing default-deny because corner cases can inadvertently result in default-permit behavior. For example, it is insufficient simply to assume that all resource sets have some non-zero set of claims required for access, and then accept an empty set of supplied claims as sufficient for access. See [UMA-Impl] for further discussion.” AI: Eve: Put placeholder in UIG for this discussion. Relatedly (slightly distantly), Andi notes that Section 2 says that the RS (not the AS) “MUST” limit access once the resource set has been put under protection (that is, registered). But in our new Sec 3.3.3, we have only lowercase “The resource server must not give access in the case of an invalid RPT etc.”. But maybe the latter really should be a “MUST” even though we can’t test for it. New issue: The “must not” in Sec 3.3.3 should be changed to “MUST NOT” to match the MUST in Sec 2. https://github.com/KantaraInitiative/wg-uma/issues/198 Don’t need to discuss XSLT verb rendering. https://github.com/KantaraInitiative/wg-uma/issues/223 Add the registration of “permissions” in the token introspection registry now, because it already exists. https://github.com/KantaraInitiative/wg-uma/issues/219 We should be fine in RSR with the 405 error for all unsupported methods. https://github.com/KantaraInitiative/wg-uma/issues/185 Should the RS be suspicious of the AS with respect to the user_access_policy_uri? Domenico is thinking that the RS had better trust the AS! If it can’t trust that URI, then it can’t trust the RPTs etc. either, and we’re in real trouble. :-) We’ve already required TLS. But what if the AS has gone rogue in this case? Maybe we can say something very brief about the fact that the RS must trust the AS for a lot, including this URI. What is the realistic risk? The RS, trying to do something convenient for the RO, could redirect the RO to a page that has malware in it. If the RS were to check that the URI is fully qualified and matches the known AS host and scheme, that would do a ton to mitigate the risk. At least it would be sending the RO to the same AS that it’s been dealing with all this time. https://github.com/KantaraInitiative/wg-uma/issues/86 We would love to be able to force the AS to faithfully represent elements registered by the RS that are intended for the RO’s user interface. Let’s continue to leave this for the “BL” level, not the “T” level, of specification. No action in the RSR spec for now. Domenico notes that in Italy, the parties are required to sign something. This is truly at the “agreement” level. This may relate to Adrian’s intentions around his new issue #224, and similar follow-on opportunities. There were cases in Italian civil law that relate to this requirement. (We won’t deep-dive into this for now, but #224 is about Accounting for Disclosures, which is similar to Sal’s idea of an “exception notice”. It’s not for a V1.0.1 timeframe, but we’re warm to the idea! And it relates to consent receipts nicely.) https://github.com/KantaraInitiative/wg-uma/issues/205 Since the client in the “one-down” position of having to trust the AS more than the AS trusts the client, the realistic business risk (vs. the “raw” threat) is quite low. Given that, and given the fact that if we don’t require clients to doublecheck the AS’s work they won’t do it :-), should we just keep the current spec wording? Then again, maybe the AS is just broken, and not malicious. Should we add an in-line note that the client SHOULD check that the ticket is the same? In that case, our rationale for having the AS save the client work is pointless. If we force the client to save the state, then the AS doesn’t have to do anything, and there’s nothing to get wrong! It means the client has to do a bit more work, guaranteed, but it was looking like it had to anyway. IOW, if it had to save state to check the AS’s work, which the AS did in order to save the client some work, then the client saved no work… Is there any other rationale at all for the AS returning the ticket? We don’t think so. But taking away a MUST would be backwards-incompatible. So let’s discuss this on Thursday. New issues that gathered overnight: https://github.com/KantaraInitiative/wg-uma/issues/225 Andi’s new issue suggests seating the “presumptively protected resource” note more firmly into the Sec 1.3.1 context. Eve likes it so much that she suggests doing this with each of the instances. Okay, let’s give her an editorial instruction to do so. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Bunch of spec cleanups to take a look at
by Eve Maler 08 Sep '15

08 Sep '15

Hi folks— Thanks to Justin’s eagle eye, we’ve been able to clean up 2 dozen-plus issues in the two specs. That's just about all of the issues with labels “V1.0.1” and “editorial”, and several more. Tomorrow in the ad hoc telecon, it would be great to have some quick discussion of the following issues, whose solutions were not quite so obvious: https://github.com/KantaraInitiative/wg-uma/issues/144 https://github.com/KantaraInitiative/wg-uma/issues/194 https://github.com/KantaraInitiative/wg-uma/issues/198 https://github.com/KantaraInitiative/wg-uma/issues/223 https://github.com/KantaraInitiative/wg-uma/issues/219 https://github.com/KantaraInitiative/wg-uma/issues/185 https://github.com/KantaraInitiative/wg-uma/issues/86 https://github.com/KantaraInitiative/wg-uma/issues/205 …and a bit of review of the solutions I committed for these issues, which were not editorial in nature: https://github.com/KantaraInitiative/wg-uma/issues/206 https://github.com/KantaraInitiative/wg-uma/issues/210 I’ll ping the “UMA Chat” room on Skype to see who-all might be around in addition to those who already expressed interest. As a reminder, we’re meeting roughly 8-10am PT (not sure we’ll go that long). Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Draft specs from today are up (for your review by Monday)
by Eve Maler 06 Sep '15

06 Sep '15

Hi all— Please take a look at the draft specs and submit any issues you see to GitHub. This is intended to be your last call prior to our Public Review vote: Core 2015-09-03 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1-2015-09-03.html> RSR 2015-09-03 <https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1-2015…> As you review, please keep in mind these still-“live” questions: Okay with final permission ticket section <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1-2015-09-03.htm…> wording? Is “without an RPT” appropriate in notes like this one <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1-2015-09-03.htm…> (which appear several times in Core), versus “without an access token”? Does the Core doc restructuring (to satisfy issue #179) work? (I sure hope so…would hate to have to undo it :-) And keep an eye on the top of the GitHub issues list <https://github.com/KantaraInitiative/wg-uma/issues> for other issues you may want to weigh in on. Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from UMA legal subgroup telecon 2015-09-04
by Eve Maler 04 Sep '15

04 Sep '15

Please see below for the meeting notes. ==== 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. ==== Attending: Eve, Adrian, Dazza, Mark, Jeff Next steps: What’s the right thing to do — validate the non-legal experts’ understanding as expressed in the blue text in the “UMA as Restatement of Agency” doc? Dazza suggests doing the “restatement of agency” exercise on the simpler OAuth mode, and then build up to UMA. Since UMA is different from OAuth, start with UMA? Unless OAuth is going away, it’s best to start with it. And UMA, of course, has “OAuth inside”! The protection API token and authorization API token are both formed from OAuth. Part of the ambiguity in agency law is that you have a Principal that is a person, and then you have a Third Party that doesn’t yet have a relationship with that Principal. So we have to live with the discomfort of identifying the AS/RS in OAuth as a Third Party even from step 1. Is agency law even the right body of law? It’s not perfect, but it's the best one for now, on the way to contract law! AI: Eve: Develop "negative use cases” for the “Attempt at UMA flow with mappings (incomplete)” portion of the new document. Adrian serves as an expert witness on exactly such matters as provider responsibility in the event of a breach. There is real economic value at stake. AI: Dazza: Look into having one of his students write up a "legally refined" version of some of our outputs. AI: Eve: Put OAuth mapping into GitHub wiki. Next steps: Adrian and Eve walk through attempted UMA mapping to Agency Adrian and Eve walk through import of “ROI form goals”/"business goals" to our work Are we ready to think about deliverable types yet? Role of Purpose Specification to our work? Essential to or separable from our work? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

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