- WG-UMA - mailman.kantarainitiative.org

Use signed JWT as RPT?
by Mike Schwartz 01 Oct '15

01 Oct '15

UMA-tarians, One of Gluu's customers has proposed using a JWT as the RPT token signed by the AS to avoid the call to the introspection API (for better performance). It didn't seem like a horrible idea, or anything that would break the security. Any thoughts? Am I wrong--is there some inherent security advantage to calling the introspection API? - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO

3 2

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

30 Sep '15

Fri Sep 25 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> Examine/confirm top meta-use cases RS is concerned about outsourcing protection functions to AS RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved Discuss/prioritize business models Organizational consumer-facing access federation Industry access federation Free-love access federation Other Determine roughly what our outputs should look like Develop a list of unknowns without which we can’t finish our work Attending: Eve, Jon, Adrian, Jim, Thomas, Domenico, Dazza, Ann Meta-use cases: 1. RS-AS: RS is concerned about outsourcing protection functions to AS. 2. RO-RqP: RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved. Are these the top pairwise relationships to be concerned about? Adrian is concerned about the case where the technology that is executing the RO’s instructions is sovereign — that is, RO=AS. The analogy with SSO/authentication-as-a-service breaks down when we get to this point, because authentication is a kind of reputation service, authenticating the RO’s identity. It has to be a third party. By contrast, the AS can be wholly "first-party”. Should we add a third item about this? Yes: 3. RO-AS: RO is concerned that the AS fully represent her, and thus seeks to be able to build (vs. run or outsource) an AS so that it will never need to "have a privacy policy” because it’s hers. Business models: 1. Organizational consumer-facing access federation: Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS. 2. Industry access federation: Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.). 3. Free-love access federation: :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in. The reason it’s “BLT” is not just because, Bacon!!!, but because business comes first! The draft NIST Privacy Risk Management Framework notes, very sensibly, that you must start with a business goal. What business model do the HIEs of today represent? Are they focused on a single provider? They’re vertical-specific, regional, and voluntary on the part of the RS (hospital). They struggle mightily to get adoption and achieve a sustainability model. Under HIPAA, they decided to extend HIPAA to treat data aggregators (an HIE is one) as a business associate. This gives flexibility. There are about 80 HIEs around the country, and only NY (as far as we know) has enabled patient access. It’s the province of big hospitals. The HIE only stores identity information for patient matching. Data is exchanged through Direct messaging. An HIE registers encounters, and it manages consent. Eve suspects that HIEs anomalously reflect today’s US HIPAA regulations, and we’re building something specifically patient-centric. Further, that they are a special case of an industry access federation because they are exposing heterogeneous services. We explored the industry access federation example a bit more by looking at SmartHomeDB <http://www.smarthomedb.com/>. #1 means you’re “on the plantation”. #2 means the data never even enters the plantation; it stays in its native environment, the way data can stay on a phone. We agreed to focus first and foremost on #2 because it meets important UMA goals, requires legal support, and appears to be the critical model required for the IoT. What should our outputs be? Should we be developing sample pairwise agreements at the “client credentials issuance” stage because the terms and conditions at that stage are so important? There’s a B2B stage, and a B2C stage. The opportunity to issue those credentials always seems to come with a “gate” that has business agreements associated with it. AI: Dazza, with Eve as backup: Bring a source of contract terms for getting OAuth client credentials. AI: Jon: Bring preliminary thoughts on IoT liability tensions. AI: Jim: Pose an answer to the question “ What would a sane, brilliant, non-powerless consumer, with some bargaining power (or friends at the EFF and Justice Department) expect from an agreement?” AI: Dazza: Create a “business models page” on the wiki, numbering the business models. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 4

Some examples of terms of service for getting "social" OAuth client credentials [legal]
by Eve Maler 30 Sep '15

30 Sep '15

I started collecting a few of these here: https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Ter… Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

4 6

UMA for our VRM Robots
by Adrian Gropper 26 Sep '15

26 Sep '15

Apologies for cross-posting an article that could be a seed for discussion at IIW. (Apologies too, for having lost the source that pointed out this article to me.) http://idlewords.com/talks/what_happens_next_will_amaze_you.htm The UMA Authorization Server (or something very much like it) will be the link between our Vendors and our Things. The AS protocols and practices will become the essence of our robot's operation and enable VRM. Whether the robot belongs to me or to Them is central to "what happens next". See you at IIW. 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

Project Brandeis and Human-Data Interaction [legal]
by Eve Maler 25 Sep '15

25 Sep '15

I had an opportunity to have a very wide-ranging chat with David Bray, CIO of the FCC, yesterday, about data sharing, the IoT, UMA, and more. He subsequently pointed me to some resources about DARPA’s Project Brandeis, about which I’d heard, but I hadn’t really delved into it very far. It’s a new research project to come up with technology solutions for privacy related to (simplifying a bit) big data: http://www.darpa.mil/program/brandeis https://www.fbo.gov/index?s=opportunity&mode=form&id=806e298e3bda3a09fd13d4… https://defensesystems.com/articles/2015/08/25/darpa-sri-brandeis-data-priv… These led me to something called Human-Data Interaction: http://hdiresearch.org/ http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2508051 The paper will sound familiar to a lot of us who have been around VRM, PDS’s, and such for a long time. It’s good stuff, but not entirely new. In fact, they introduce a term, “data statement”, that sounds pretty close to consent receipts. :-) I put the [legal] tag on this note specifically because the paper has three themes — legibility, agency, and negotiability — that may *possibly* speak to our work. In any case, I thought I’d draw the attention of all of the “BL&T" participants to this stuff. Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Next steps [legal]: Homing in on concrete "business models" and deliverables
by Eve Maler 25 Sep '15

25 Sep '15

This is the message I promised legal subgroup folks last week, after gathering feedback from a few folks. I heard a couple of themes: Appetite to cut to the chase and discuss actual "business models” and concrete legal constructs (e.g., finally discussing licensing) Agnosticism about how we capture and store our results and deliverables (GitHub, Confluence, Word, whatever) These both make a lot of sense to me, particularly in the context of our tightening timeline. There’s always a danger of Zeno’s Paradox of Standards-Making: Before you can get halfway done, you have to get halfway to that intermediate point, and halfway to that second point, and so on, such that you can never finish. :-) So here are the tasks I recommend we undertake. 1. The meta-use cases — liability tensions, if you will — of most interest have been staring us in the face the whole time (they’re in our mission statement), and I suggest we focus on these two meta-use cases exclusively for the 2015 period: RS is concerned about outsourcing protection functions to AS RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved If anyone has others they would like to make a case for, we can put them on the list and discuss (briefly) whether reprioritizing makes sense. 2. “Business model” is a term that I heard in the conversations. It’s in quotes because I don’t want to scare away anyone who would prefer to think of this in more Alice-friendly terms; it simply means is the nature of the ecosystem where the parties interact (I sometimes call this a “deployment ecosystem” or a “topology"). We need to prioritize the business models for which our subgroup needs to create outputs. Here are a few to consider, going from simpler/smaller to more complex/larger: Organizational consumer-facing access federation: Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS. Industry access federation: Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.). Free-love access federation: :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in. If you have others in mind, or want to adjust these, great. 3. We need to determine roughly what our outputs should look like, so we know what we’re driving towards. Is it model clauses? Something different/more? Let’s just get an idea. 4. If we think about the two meta-use cases in light of each of the business models of interest, and in light of what we’re supposed to deliver, no doubt the experts in the room will notice all the things we’re missing! We need to develop a list of unknowns without which we can’t finish our work. I’m hearing that this could be anything from jurisdiction to “policy” (not authorization policy, something else? policy framework?) to use case specifics to whether we’re using a licensing model vs. a contract model! Please let me know what you think of this approach, on the list or separately. I’ll send an agenda with dial-in details as usual; the above may take us two meetings’ worth of time to go through…but maybe not, if we’re focused and try to do some homework ahead of time. Thanks! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 4

Reminder: UMA legal subgroup telecon 2015-09-25
by Eve Maler 24 Sep '15

24 Sep '15

Fri Sep 25 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> Examine/confirm top meta-use cases RS is concerned about outsourcing protection functions to AS RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved Discuss/prioritize business models Organizational consumer-facing access federation Industry access federation Free-love access federation Other Determine roughly what our outputs should look like Develop a list of unknowns without which we can’t finish our work (Email troubles — sorry for the delayed agenda!) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from UMA telecon 2015-09-24
by Eve Maler 24 Sep '15

24 Sep '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> Minutes Public review status Please retweet <https://twitter.com/UMAWG/status/645674926137958400> the @UMAWG tweet about the public review! Take a look at the new Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> document. UIG status For the Organizations as Resource Owners and Requesting Parties section, is there really that much to say? Mike's folks are developing a sample resource server and an UMA client in Python, and will use the client credentials flow. His use cases typically use this grant flow. This will be Hello, World level. The org=RO circumstance is always the case for Mike, but the RqP might be an org or a human. For the Ensuring Resource Server Access to an Authorization Server When the Resource Owner Is Offline section, it's worth pointing out that the RO might not be a human at all, in which call "offline" isn't the right word. We might also want to mention "break glass" as a phrase specifically, since everybody knows this phrase. We don't want to burden developers with trust framework knowledge, but it might be a good idea to call out to the Binding Obs at this point, because it's around here that UMA protection might tip over into enterprise access management. AI: Eve: Make edits to the Ensuring Resource Server Access... section. 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. 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. AI: Eve: Ask Allan to write up why default-permit isn't a good idea. Logistics Next week, let's do a quick check-in on UIG status and Roland interop topics if possible. Let's go back to our previous usual pattern of weekly "ad hoc" meetings and last-week-of-the-month "quorate" meetings. (LATER: Eve notices that the last week of October would be IIW, when we won't be having a meeting, so let's strive for reaching quorum on both Oct 22 and Nov 5 so we can handle Public Review issues and results.) 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. Attendees As of 10 Sep 2015 (post-meeting), quorum is 6 of 11. (François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Sourav, Arlene, Mike) Eve Arlene Maciej François Mike Domenico Non-voting participants: James Katie Ishan Scott Marcelo Jin Regrets: Thomas Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com>

1 0

Notes from APAC-friendly UMA sync 2015-09-24
by Eve Maler 23 Sep '15

23 Sep '15

Attending: Eve, Nat, Paul Nat suggests that, once we have a draft that can be reviewed, we should send a request for comments to the Kantara Liaison Committee so that it can reach out to, e.g., the Article 29 Working Party and APEC (http://www.cbprs.org) The liaison that Kantara has is with ISO/IEC JTC1 SC27 WG5, of which the Article 29 WP is a member. The forthcoming EU GDPRs may impact what we’re doing here. This has been a topic of consideration for us, at least broadly; Mark and Eve have discussed some of the specific GDPR proposal wording. Paul will dig up a link to an institute in Sydney that has done work on global privacy issues, which might be another group from which to seek comment. Reminder: No APAC sync meeting next week (making our schedule be effectively “every three weeks" for a little while). Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

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

23 Sep '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> Date and Time Thu Sep 24, 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 Quick hits: Let's go back to our previous usual pattern of weekly "ad hoc" meetings and last-week-of-the-month "quorate" meetings Public Review status and outstanding comment review UIG review and next steps Interop and IIW planning AIs AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0