- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2015-10-22
by Eve Maler 20 Oct '15

20 Oct '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-10-22 Date and Time Thu Oct 22, 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 Public Review status and outstanding comment review Considering our Independent Submission stance of record: is there news? Permission registration extension spec idea How are we doing on other outstanding AIs? If time: Consider charter revisions/cleanup AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Re: [WG-UMA] A Wallet Authorization Server
by Eve Maler 19 Oct '15

19 Oct '15

Thanks for the reminder and the code, Phil! I know of plans to convene sessions on "UMA developer resources” and interop, and we typically hold an “UMA 101” session (which, in deference to Justin, we will have to call “the 101 on UMA 1.0.1”, or perhaps “the 411 on 1.0.1” or something). Oh, and I’ve also signed up to do one of the speed demos, showing what I’ve been calling V2 of my UMA demo built on the OpenUMA project. Eve > On 19 Oct 2015, at 9:55 AM, Phillip J. Windley Ph.D. <windley(a)gmail.com> wrote: > > If you’re not already signed up for IIW next week, use this code to get 25% off and come talk about this in person: > > https://iiwxxi-21.eventbrite.com/?discount=UMA_IIX_XXI_25 <https://iiwxxi-21.eventbrite.com/?discount=UMA_IIX_XXI_25> > > This is the kind of conversation we need at IIW. > >> On Oct 19, 2015, at 10:14 AM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: >> >> Some food for thought... >> >> I suspect reasonable people can disagree on what the complex parts are and what the simple parts are, depending on what parts of a system they are responsible for. >> >> There has been a robust conversation in IIWs past about the proposition of a server that would be totally controlled by the individual. Adrian convened a very interesting session at IIW 20 that resulted in these notes <http://iiw.idcommons.net/My_OWN_$5/mo_UMA_Authorization_Server>, called “My OWN $5/mo UMA Authorization Server”. It would be cool to do this again and see how far we’ve come. It’s been very tough to get “user-centric identity/access servers” going as a real-life attractive proposition, but it could still happen at some point. >> >> I had an ongoing conversation with Steve Greenberg* this weekend, who pointed out a curious phenomenon: In the world of identity, we’ve had the “T” for a very long time, but we’ve sometimes struggled with the “B”, and the “L” situation is pretty immature. (Which is why I glommed on to Tim Reiniger when I first met him — he had a lot to do with authoring the Virginia digital identity law!) But in the world of consent and trust and so on, it’s really about agency — and we’ve actually had the “B” and “L” elements for a long time; the “T” element is the new guy at the table. [He wants me to call him “Steve Greenberg, noted raconteur and bon vivant” :-) ] >> >> OAuth (6749 and 6750 together) is about 96 pages on my printer. OIDC Core all by itself, ignoring the other important specs, is 93. UMA Core is 34 and RSR is 23. At least by the metric of the technical complexity that it adds on top of the other pieces, I’m not sure UMA’s “T" is all that complex. >> >> As for “where the beef is”, in my own world I have several examples of business model <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Business-Models> #1 (easy) coming up, and, increasingly, some instances of business model #2 (medium). Business model #3 — Adrian’s goal — is the hardest. The reason we have a legal subgroup at all is to accelerate comfort with/reduce inhibitors to deploying the harder cases. The WG’s work is generally “(B)T” at this point, and the legal subgroup is generally “BL”. >> >> Looking at the provided diagram, I’m not sure I understand the blockchain connection, as UMA is, by design, identity-ignostic and you can get pretty far without having to use “the same identity” in many UMA-related contexts (e.g., an RO can use a different identity at each RS and the AS and — when acting as an RqP — at each client, and authorization can be based on non-uniquely identifying factors of an RqP through “claims-based access control”). Would love to understand this better. >> >> FWIW… >> >> Eve >> >>> On 16 Oct 2015, at 6:20 PM, Adrian Gropper <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: >>> >>> On Fri, Oct 16, 2015 at 3:43 PM, Dazza Greenwood <dazza(a)civics.com <mailto:dazza@civics.com>> wrote: >>> The B comes first because it is the meat. If you only have T and even L and T, you should be asking: Where's the Beef? >>> >>> I should know better than to argue with a lawyer, in public, but I can't resist... >>> >>> UMA is already too complicated for its own good. I've been in a position to work on UMA-related things as much as anyone from the B perspective except probably Eve. The legal subgroup discussions are thrilling, but they are not headed in the direction of reducing UMA's complexity. CommonAccord and consent receipts will be huge contributions to UMA but we need to consider the UMA adoption model as a whole. >>> >>> UMA's path to success lies in packaging the LT goodies with the simplest possible B by giving away a fully functional personal Authorization Server. This will provide the essential reference implementation at the root of any new standard. It's unreasonable to expect anything as complex as UMA to take off when people have to digest OAuth, OpenID Connect, federation, servers, scopes, clients, and agency before a single transaction takes place. >>> >>> The B I'm proposing is a non-profit community chartered to promote UMA to individuals as a component of both decentralized and corporate services. The L and T can include CommonAccord and MVCR and any other technology that will reduce the barrier to UMA for RS and C developers. >>> >>> Adrian >>> >>> >>> On Fri, Oct 16, 2015 at 10:35 AM, Adrian Gropper <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: >>> Available as a service: could be satisfied with a $5/mo VM and a https://letsencrypt.org/ <https://letsencrypt.org/> cert? >>> Speaks standard UMA: can WAS be a profile on UMA 1.0.1 or does it need UMA 2.0? >>> Dynamic client registration: ROs can choose their app (store) whitelists - what has this to do with UMA? >>> Acceptable to other entities/parties at the business and legal level: what can UMA do to help this? >>> That last one is the key to UMA adoption. If the legal and business barrier is low then adoption might follow the Bitcoin / blockchain model where adoption is driven by a combination of branded centralized services and pure p2p energy. CommonAccord and emerging blockchain inspired governance models will also help reduce the legal and business barrier. >>> >>> Where's my BLT sandwich? >>> >>> Adrian >>> >>> >>> On Thu, Oct 15, 2015 at 9:31 PM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: >>> As long as the AS is available as-a-service (that is, doesn’t frequently get shut down), speaks standard UMA, handles the more “dynamic” patterns (such as being able to hand out client credentials readily to OAuth clients it hasn’t met before), and is acceptable to other entities/parties on a business/legal level and vice versa (whatever those constraints and concerns might be), I’m not sure what other compatibility concerns there are. >>> >>> Eve >>> >>>> On 15 Oct 2015, at 1:19 PM, Adrian Gropper <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: >>>> >>>> Imagine the authorization server as an on-line wallet: secure, compatible regardless of jurisdiction, and owned. It would share a lot of the attributes and business issues of Bitcoin wallets. For lack of a more inspired name, I will call it a Wallet Authorization Server or WAS. >>>> >>>> Like Bitcoin wallets, the WAS will be delivered to individuals as either a VM they can run on hardware / VMs they control or not. Individuals will choose sovereignty vs. convenience. >>>> >>>> Do we want to drive future versions of UMA in this direction? If so, what are the minimum essential components of the WAS in order to make it compatible with all UMA resource servers and all clients that are willing to support a truly user-centric model? >>>> >>>> Adrian <http://patientprivacyrights.org/donate-2/> >> >> >> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com> >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> >> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

If I didn't mention this already: new Intro to UMA page
by Eve Maler 19 Oct '15

19 Oct '15

http://kantarainitiative.org/confluence/display/uma/Introduction+to+UMA Let me know what you think. And feel free to add (or suggest) items. Thanks! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 3

Notes from UMA legal subgroup telecon 2015-10-16
by Eve Maler 17 Oct '15

17 Oct '15

Fri Oct 16 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> Report from the APAC-friendly UMA sync discussion <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/1vA-frUlo…> Take a look at the latest CommonAccord artifacts and progress What are the appropriate next steps and timeline? What artifacts will give concrete assistance to UMA deployers in 2015? Anything worth retaining/saving from Binding Obs? Should we sunset it? Attending: Eve, Steve, Ann, Domenico, Andrew, Jon, Tom, Dazza, Jim, Adrian, Tim, Paul, David David Maisenberg is a nonpracticing attorney who works with startups and law firms - "UMA is the solution" to many things he’s working on. In discussing some of the challenges of multi-AS environments that are specific to access control propositions (e.g., might Alice want to control whether the RqP is allowed to share her resource further? might the answer want to turn on which AS the RqP has chosen?), Adrian points out that this is related to 42CFR Part 2 regulations. This relates to substance abuse/mental health data. You can ask a patient to consent generically to release; you have to list explicitly who will see it, and come back to the patient if you want to share it beyond that circle. And data must be tagged with that specific type of sensitivity, and be redacted to the point of obscuring whether it ever existed if it wasn’t consented to be shared. What if Alice were in jurisdiction A and Bob were in jurisdiction B? CommonAccord could handle multi-jurisdiction challenges. We would try to cover as much of the jurisdictional differences as we can ahead of time, but it may be an 80/20 approach. “Lawyers are there for error correction” — could be before or after the fact. Text could be tweaked as further deltas are identified. Could the rule set text call out to the relevant laws/rules by reference? “These rules are subject to the laws of the state of MD” or whatever. There are limits to this approach. What would be productive to work on: UMA-specific model text, non-specific text, both? Could be both. If we could throw together some candidate “stacks” (the “legal stack” and “technology stack” concepts of CommonAccord) and try them out, that would be valuable. Jim’s candidate UMA text was just thrown together — don’t take it too seriously! Model forms would also be hugely useful. GA4GH has a lot of similar problems. Finally, at a granular level, what would the layers of consents, resource exchange, etc. be? This sounds like it’s about “semantic interop”. Jim sez: it’s “technical emojis”. :-) Each community of interest might have different sets of these. So, three tasks: stacks, clauses, semantics. For the stack task, how does the CommonAccord logic work regarding flowing through to different jurisdictions? It appears that once you’ve designed and tested these flows, they can be captured and reused. And you can scope the results, so that (e.g.) the French guys can work on an outline independently when it’s specific to them. For the clauses task, how do you ensure that (e.g.) the French and English versions mean the same thing? This is metaphysical and cultural. The experts in that field end up having to make a judgment. In Germany, the shape of a consent may be different from in the US. (Eve points to this book <https://en.wikipedia.org/wiki/Le_Ton_beau_de_Marot>!) For the stack and clauses tasks, are these anticipated to be pairwise, and if so, do we simply focus on the 3-4 pairwise “liability tensions” (meta-use cases) that have been identified as being of most interest so far? RO-RqP: for example, purpose-of-use or other constraints on further downstream use (as discussed in this chain-link confidentiality paper <http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818>); and our question about the relevance of licensing comes up here (IP/real property rights) RS-AS: traditionally, services have done authorization jobs themselves and now we’re talking about their outsourcing this; they might have security/privacy requirements RO-AS: would the resource owner feel comfortable trusting, say, a “social” AS to do this job correctly? AS-(OAuth client): we do have some example agreement text <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Ter…> for this in the social IdP realm Jim suggests looking at existing examples and starting from there. Jon asks: How pairwise or non-pairwise are these, really? Delving into the distinction between “informed consent” and “authorization” and statutory use, in US healthcare regulations, there are implications regarding whether you have to do Accounting for Disclosures. There are perhaps interesting distinctions between different ways of deploying UMA-enabled applications when it comes to whether something counts as “consented” sharing. If your app (RS) provides a “share” button, is that consent? If your app (RS) hooks up to an AS that has a “share” button? If your AS supports a “pending requests approval” flow? If your app (RS) and client and AS collaborate to simulate a typical OAuth flow that is guaranteed to let you “uncheck scopes”? Next steps: AI: Steve, Dazza: Research “meaning of consent” and UMA usage patterns for next week. AI: Eve: Share links with Steve/Dazza to help in their task. AI: Jim: Help the rest of us understand how to “build stacks” — a tutorial. Dazza has announced the FutureCommerce Legal Hackathon! Should there be an UMA track? He’ll send out a link about this! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 2

Noting a few calendar adjustments
by Eve Maler 16 Oct '15

16 Oct '15

Let’s try and review all the outstanding public review-era comments in next week’s WG call. (Maciej, shall you and I do the outstanding stylesheet work as well, this coming week?) I’m going to remove the APAC-friendly sync meeting on (Pacific) Wed Oct 28/(APAC) Thu Oct 29 because it conflicts with IIW. Voting participants, please mark your calendars for the Nov 5 call so that we can make quorum and dispose of the post-public review comments/specifications and hopefully move them to LC consideration as Draft Recommendations for All-Member Ballot as the next step. I’ll be on vacation Nov 7-14; I'll plan to cancel the APAC, WG, and legal calls that week (as is our habit) unless I get offers from volunteer chairs pro tem by Monday. Any questions? Let me know. Thanks! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Ninth Circuit taking up password sharing legitimacy as authorized access [legal]
by Eve Maler 16 Oct '15

16 Oct '15

https://www.washingtonpost.com/news/volokh-conspiracy/wp/2015/10/15/shared-… ...and this is why explicit delegation without credential sharing and without mental state guessing would be so awesome. :-) Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Reminder: UMA legal subgroup telecon 2015-10-16
by Eve Maler 15 Oct '15

15 Oct '15

Fri Oct 16 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> Report from the APAC-friendly UMA sync discussion <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/1vA-frUlo…> Take a look at the latest CommonAccord artifacts and progress What are the appropriate next steps and timeline? What artifacts will give concrete assistance to UMA deployers in 2015? Anything worth retaining/saving from Binding Obs? Should we sunset it? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from UMA telecon 2015-10-15
by Eve Maler 15 Oct '15

15 Oct '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-10-15 Minutes Public review status There appear to be no big comments yet. We have a few editorial/minor text comments. We should be prepared to vote on edited versions of the specs on Nov 5, and make quorum. Eve and Katie have been getting quite familiar with using the V1.0.1 versions of the specs. Mike and folks will be looking closely at them for OxAuth purposes. AI: Eve: Publish low-level UMA swimlane and WSD source code (with new V1.0.1 spec section references) for general use. Mike's diagram <http://ox.gluu.org/lib/exe/fetch.php?media=oxauth:umademodetail.png> (currently up to 33,708 hits!) seems very popular. Robert notes that the diagrams by themselves, without a narrative, kind of start in the middle (or at the end). Should we be providing a new area of the site for videos, training, documentation, etc.? Stories from the Alice and Bob perspectives could be good too. Intro to UMA? UMA 101 would be ambiguous. UMA for Beginners? And then we could have Advanced UMA materials etc. AI: Mike: Create a new UMA video/screencast. An interesting discussion as part of this intro material would be a discussion of best practices around scopes and scope design. See, e.g., this page <https://developers.google.com/identity/protocols/googlescopes?linkId=178862…> that catalogues Google API scopes that are actually used. AI: Eve: Create new wiki area for UMA intro material. Report from UMA Dev Roland will have some RS library work done by IIW. Mike also has a sample library effort going, at the level of Hello, World. We can perhaps combine efforts under UMA Dev to accelerate that effort. Who from this call is at IIW? Eve, Mike, Adrian, Sarah, Maciej, Jin, Justin. Surely we'll convene a session on this topic, if not more. Independent Submission Originally the WG had planned to contribute our specs to IETF, with the hope/anticipation that the OAuth WG might pick up the specs as part of its work stream. Subsequently, when Kantara softened its requirement for contributions elsewhere, the WG had decided to go the Independent Submission to the RFC Editor route (resulting in Informational RFCs) because of the value of the RFC imprimatur and the relative lack of likely impact on the specs through that process. Now we are reconsidering. Pros of going the Informational RFC route: The RFC imprimatur does seem to be valuable to some; Debbie has noted this. The specs get more "marketing". Cons: The process of AD review (and, possibly, WG attention) is onerous. The confusion around multiple versions of specs, KI vs. I-D, is potentially considerable. The original motivation for contributing I-Ds was that people in IETF don't pay attention to spec input unless it's in the I-D/RFC ecosystem, but that hasn't help our cause to date, as far as we can tell. Justin proposes updating the I-Ds we've got now with I-Ds that have no content except for URLs that point to the "real" specs. Justin notes that his implementation of RSR in the non-UMA context, prior to implementing it for UMA, had to be changed considerably to work with his later UMA implementation. So maybe it's not as modular as we think. Can we learn more about Debbie's rationale? If we do go the Informational RFC route, in fact it wouldn't go through an IETF WG; does that impact her thinking? Andi cautions that some who are interested to deploy UMA may not take it seriously if it doesn't come through a certain organization. Mike looks at the SEO/marketing angle. Even with possible confusion, getting the specs out there through more channels would be valuable. AI: Eve: We apparently need more information about who would reject UMA if not published as an RFC; float the question with those who care about this. Permission registration extension idea AI: Eve: Send email about permission registration extension ideas. 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 Mike Robert Maciej Non-voting participants: David Maisenberg - attorney (non-practicing) - works with biotech - didn't know about UMA but was looking for it! - trying to get up to speed - hopes to contribute to writing and research - based in Colorado Sarah Steve Greenberg - technologist/consultant - obsessed with delegated consent and identity - following with interest Adrian Katie Justin Ishan Jin Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Some UMA deltas related to [legal] goals
by Eve Maler 14 Oct '15

14 Oct '15

Completing an action item I took (with Adrian) on Friday’s legal subgroup call: We had done some work a few weeks back to analyze various deltas between the “UMA-that-is” and the “UMA-that-he-posited” could solve many of the concerns of potential RS’s in the healthcare space. I captured these in a GDoc table <https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS…> (not the friendliest format, nor perhaps even accurate). I’ll paraphrase/correct that information here and comment further… In the GDoc, We started calling these “technical UMA safe harbor propositions”, meaning that if UMA could build in some solutions at a technical layer, then it could powerfully convey to RS’s that they would be safe in outsourcing authorization to an AS chosen by Alice (our RS-AS meta-use case). Don’t take the appearance of the phrase “safe harbor” to mean that other thing. :-) Here were the propositions we looked at and the solution spaces I thought were viable. I’m sure there are other potential propositions beyond these. Accounting for Disclosures at AS (HIPAA calls these “accounting of disclosures”.) This is a regulatory requirement that apparently isn’t really honored yet. The idea is that patients have the right to know who has received their health information for reasons other than treatment, payment, or health care operations, or disclosures specifically authorized. In other words, it’s a kind of monitoring capability. Can this be done in UMA V1? Technically, only “attempts at access” can be detected at the AS at all, and this is only if the RPT was introspected by RS at the AS. Token introspection at the AS is required by the default token profile, but it needn’t be done if (e.g.) the token can be cached and is still fresh. And if the token introspection revealed that the client isn’t authorized, or if the RS maliciously took action that was contrary to what the token said, then the introspection wouldn’t be a good clue as to whether anything was disclosed. Can UMA be extended to do this? The UMA AS-RS communications channel could be extended to let the RS report actual accesses to the AS, so that A4D could be made interoperable. Can software outside of UMA add value to do this? An UMA-enabled software system could throw events about and log access. RS takes client/RqP-dependent actions on access requests Normally the RS knows nothing at all about the client or requesting party that approaches it. But even if the AS says the client has a valid token with the right permissions in it, the RS may want to reserve the right to make up its own mind. Adrian has called this “you cut, I choose”. I don’t like this analogy because it implies 50/50; I prefer the federated identity analogy (which he hates!), which is that a relying party always has the right to refuse service. Can this be done in UMA V1? In the UMA V1.0.1 spec, we added/tweaked text to make clear the RS’s rights: “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.” Can this be done on a business/legal level? Yes. We have woven this recommendation throughout the spec, e.g. “Parties operating and using UMA software entities have opportunities to establish agreements about the parties' rights and responsibilities on a legal or contractual level, along with common interpretations of UMA constructs for consistent and expected software behavior. These agreements can be used to improve the parties' respective security postures, and written profiles are a key mechanism for conveying and enforcing these agreements.” AS displays to RO notices that were contributed by RS that reflect RS’s statutory responsibilities to adhere to RO/RS contract, signed by RO (or AS?) This one is a doozy. It’s an interesting idea, but I’m not sure I understand all the ramifications. This came out of Release of Information (ROI) form discussions. Can this be done in UMA V1? No. (This was causing me to freak out, as I thought I heard Adrian claiming this was just a tiny thing that would be easy to add. :-) See his issue 224 <https://github.com/KantaraInitiative/wg-uma/issues/224> in GitHub. Can UMA be extended to do this? Perhaps an endpoint/capability for registering either only a “dead” version of the ROI, or elements of the RS/RO contract of record, could be added. Adrian has proposed that this could include a label, an endpoint for notification of changes or cancellation (in both directions), an expiration date of the contract, and an option for the RO’s unilateral cancellation since this is always their right (as it it always the right of the RS too). Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 2

Notes from APAC-friendly UMA WG sync 2015-10-14 [legal]
by Eve Maler 14 Oct '15

14 Oct '15

Attending: Eve, Gil, Allan, Colin We discussed the impending “grand unified theory” that seems to involve CommonAccord, consent receipts, dynamic OAuth client credentials issuance, etc. Some of this involves ideas for major UMA extensions or value-add on top. Allan strongly suggests that any business logic that complicates “core UMA” be layered carefully, so that it doesn’t compromise the spec. No one wants a new X.400. :-) We do have a “Modular” design principle, so we should adhere to that. There is definitely a challenge coming with “multi-AS” environments on a technical level, not just on a legal level (a la the business models described here: https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Business-Models ). How would such an environment work as we look at more complex use cases? This could give color to the “Free-Love” business model. This is where Justin has been heading with his critiques of our V1 design, and we know that certain simplifying assumptions have made certain value-add features work nicely in “single-AS” environments. On the other hand, solving all the problems of multi-AS environments is really really hard, and it impacts user experiences too. Maybe imagine that a single RO has to deal with multiple AS’s in their life. What problems need to be solved? Another piece of simplifying assumption is when the AS = IdP. When they’re not, what does this mean? What changes? What attack vectors might there be, specifically in the context of chained delegation, if there are multiple AS’s and a requesting party has a different AS? An RS might hesitate to engage in these interactions if it’s not sufficiently protected. This is perhaps precisely where we need “UMA-specific model clauses” that are not just about privacy, not just about security, but about access control that goes beyond what the technology can enforce. This is what the Binding Obs doc attempted (imperfectly) to do. The enterprise UMA use cases are where Gil comes in. Employees would have contractual requirements with their employer, for example. In these cases, corporate policy would take effect, and it would probably be single-AS for the most part (a la Google Apps for Business?), and the PAT and AAT would likely be issued silently based on those employment agreements. Actually, multi-organizational sharing/delegation that has proper trust elevation would be a great use case that goes one better than Google. :-) What if we could take this as a multi-AS use case to solve? We’d be looking at “PDP proxies” here or something, or policy sharing. XACML!!!!!! :-) (Side note: Gil is moving back to the US in January.) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0