August 2015 - WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2015-08-27
by Eve Maler 27 Aug '15

27 Aug '15

Many thanks to all the UMAnitarians who made it onto the call today — we made great progress. I really apologize for having the call run over so long. And apologies also to Jon Neiditz, who’s been attending the legal subgroup calls but for whom this was the first WG call — normally I would have had him say a few words of self-introduction… We’ll do that next time, I promise! http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27 Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the minutes of UMA telecon 2015-08-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13> and UMA telecon 2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20>. APPROVED by unanimous consent. Conclude on topic: Restricting GitHub editing Deferred. Workshop space No takers at the moment. Formatting the specs Maciej has an XSLT for turning UMA's XML2RFC source into Kantara specs. He is willing to take it the rest of the way. Let's pursue this. Issue resolution work #163/#168: Given the early stage of UMA implementations, and given the technical soundness of the fig-leaf logic for MAY/SHOULD/MUST, we are going to add the ticket parameter in the header, and greatly soften the need for the ticket body. #176: Why would an RS want to indicate to a client that it's giving it a public version of the resource, but that there is a protected version, and it can't help the client seek access to it right now? Then the client could a) know that there's more, and b) choose to try later. Should the RS try again on its own later? No, because it has no relationship with the client; why would the RS take action on its behalf? The RS could, of course, respond with a non-UMA response (which gives no hint of anything wrong). So if there's any option at all to respond with "an UMA response", then there should be some reason to use it. Suggested: A new header. James suggests (from the HTTP spec <https://tools.ietf.org/html/rfc7234#section-5.5>): Warning: 199 UMA Authorization Server Unreachable The client is not allowed to take any automated action beyond displaying this text to the RqP, but that lets the RqP know that there's "more" behind the RS. "If the RS received an XXX error from the AS, and did not receive a permission ticket, then is unable to create a WWW-Authenticate: UMA header and MUST include a header of the following form: "Warning: 199 UMA Authorization Server Unreachable"." #172: Justin is looking for more implementation guidance, which we're thinking should really go in the UIG rather than here. Should we include a cross-reference out? Let's do it. We will stick to language that supports the RFC 2119 normative assertions in the spec. #171: Eve SWAG'd some text guessing that we would require at least one scope to be registered in future. But no one?? is crazy about making this kind of a decision now. So let's revert it. #164: Goes away because there are no mandated HTTP codes anymore! #161: We are cycling on Justin's wording: Note: When a client attempts access to a presumptively protected resource without an RPT, the resource server needs to derive the authorization server and resource set identifier associated with that resource from some other aspect of the client's request. This effectively means that the resource server’s API needs to be structured in such a way that the client's RPT-free request uniquely identifies the resource set. In practice, this information likely needs to be passed through the URI, headers, or body of the request. Done. #160: Looks good; we'll get review of the whole spec later. The last STRONGLY RECOMMENDED should be in active voice, not passive. #151: We shouldn't have the AS check for URI host/scheme matching, so the second part of the third paragraph in RSR Sec 4 should come out. We don't want to add any SHOULDs. #144: Just needs s/s/z/ in AS. Shall we close all of the issues at this point? We're ready to close them and review the final text, once Maciej has done the final edits tonight. We may be ready to vote on progressing the candidate Draft Recommendations to the LC next Thursday. AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. 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 21 Aug 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike, Jon) Eve Thomas Mike Maciej Arlene François Jon Sal Non-voting participants: Sarah Ishan Mark James Justin Dazza Andi Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 1

The RS liability conundrum and use case proposal [legal]
by Eve Maler 27 Aug '15

27 Aug '15

A number of folks have been discussing liability topics in side-email, and I wanted to share some excerpted thoughts here in preparation for Friday’s subgroup call. (Unfortunately, I can’t be on the call myself; Dazza has graciously agreed to facilitate.) The top liability/adoption conundrum I think we face is the one of whether a resource server (RS) can become comfortable with “outsourcing” protection to an authorization server (AS). An imperfect but apt analogy in the identity world is the relationship between relying parties (RPs) and identity providers (IdPs). Adrian has been describing this as wanting to define a “safe harbor” for the RS. And looking at what use cases to start with, we’ve got a healthcare elephant in the room, so I suggest we tackle it and see how it goes. :-) A pattern we’re seeing in the HEART group use cases involves Alice visiting a primary care provider (PCP) for the first time; we can imagine her offering for the PCP’s electronic health record (EHR) system to connect up to "her AS" (*more about this in a sec). So we’re just talking about very initial UMA steps here, not even a whole flow, and there don't even have to be any Bobs in the picture yet (unless he’s needed for Third-Party off-screen extra purposes). (I realize not every jurisdiction in the world has private-sector PCPs, but I believe that in some public-sector systems, private PCPs work under contract to the government — might they feel liability pressure?) *What do I mean by “her AS”? Adrian and I had a really interesting exchange about what the relationship should be between the RS, Alice, and "Alice’s AS”. His take: The RS has no right to object to whatever AS Alice wants to tell it to use, because it has no stake in the matter — it just does what the AS tells it to, it gets safe-harbor protection by getting a list of assurances that either come built-in with UMA, or are can be built on top of it (I’m not sure I understand the whole list...). My take: I really want to believe this. Obviously, what I want us to be able to build is an ironclad case for this! But an RS in real life has to act as an OAuth client to an UMA AS, has to trust that the AS actually does the right thing in coughing up tokens, that it’s secure, etc. Without those “trust framework” types of assurances, it would be crazy — or, more to the point, the CEO, CFO, and CIO of the RS operator would be crazy — to allow Alice to just point to Zeke’s Nocturnal AS (motto: “We Fly By Night”). In fact, if Alice built her own AS, it could be even shadier because she could collude with it to put lots of other people’s data at risk — the AS may end up seeing identifiers and claims of requesting parties, and maybe Alice is opening up the AS at home and looking at all the data. (Not that the RS may strictly care about these vulnerabilities, but *I* care…) In case it turns out to matter for use case exercise purposes, here are some candidate variations on the chosen AS that I identified: Alice-AS: Alice runs her own AS, whether on a home server or at her ISP or in AWS or whatever Social-AS: Alice chooses her own AS, say, run by Google or Facebook or some similar service (a la social IdPs) through a “NASCAR" interface Gov-AS: Alice uses a public-sector AS Private-AS: Alice uses the AS offered by the same closed system in which the RS runs (a la the new Privacy Control Center in Google Apps) Do the scenario, the goal, the roles, and the UMA flow give enough to work with in mapping to contractual parties? Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 1

Agenda for UMA telecon 2015-08-27 (final 90-minute call before we revert)
by Eve Maler 26 Aug '15

26 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27 Date and Time Thu Aug 27 8:30-10am PT (we start 30 minutes earlier and meet for 90 minutes in August – this is the last 90-minute call!) Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Agenda Roll call Minutes approval Sample motion: Approve the minutes of UMA telecon 2015-08-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13> and UMA telecon 2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20>. Last-minute quick hits Conclude on topic: Restricting GitHub editing Any interest in Kantara workshop space on December 4 in Vienna at Rainer's European Trust and Identity Workshop? Issue resolution work: Links: recent commits <https://github.com/KantaraInitiative/wg-uma/commits/master> (click on each identifier code to review changed text in context) - issues on GitHub <https://github.com/xmlgrrl/UMA-Specifications/issues> - UMA V1.0.1 issue nominations spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…> - "sprint" document <https://docs.google.com/document/d/1c50top8X6Aqw3CEVeX_SD2THqO508ihs14QwLem…> This is intended to be our final week for considering/resolving substantive issues, so please review, and please do any outstanding spec action items! Then we are set to approve our Draft Recommendations for next-stage LC approval by Sep 3 or Sep 10 (note: Eve regrets for Sep 10) AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: UMA legal subgroup telecon 2015-08-21
by Eve Maler 25 Aug '15

25 Aug '15

Fri Aug 21 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> Analyze new (positive and negative) use cases sent to the list Is this list complete enough to be going on with, for our purposes? Do we need to capture use cases for different “topologies" (deployment ecosystems) too? What would “structuring the transaction” look like in terms of accomplishing our mission? How would consent receipts/logging/auditing come into play? (I apologize for getting this agenda out so late!) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 9

Rethinking our resolution to #161/#162 (protocol assumes one resource per URL/RO)
by Eve Maler 23 Aug '15

23 Aug '15

When we discussed this on the last call, we gained consensus around wording as follows (emphasis added — hopefully the formatting will make it through): "Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource set identifier associated with that resource without any context to guide it. In practice, this likely means that the URI reference used by the client needs to be unique per resource set.” In the previous week’s discussion, I’d had a high-level suggestion for a strategy for providing RO context, which we discussed briefly and concluded didn’t satisfy the goal to let existing APIs stay as they are, but thinking about it again, I’m not sure why that is. Let me run through it in detail. If the RS has an API that is completely generic per RO, such as a singular endpoint that normally depends entirely on an OAuth token to convey the user context, it would similarly register that singular resource set over and over for each of its many users (each using a different PAT) at an AS, getting a unique resource set ID for each in turn. It does indeed have to be prepared to associate some attribute with a resource set that can later be matched up with the PAT, and then what remains is for a client to provide that attribute somehow when attempting access with no token. Depending on the nature of the API, the context could be in a query parameter, or something in the request body. So “without any context to guide it” in our wording isn’t strictly true. The approach I mentioned on the call was what appeared in our wireframes as an “authorization code” that the AS would send in an email notification to the RqP, which the client would use in attempting access. That probably wasn’t quite the right way of envisioning the UX, but I think Justin was saying that this requires propagating changed URI structure all the way through. I don’t believe this is needed. Here are several ways to complete the PAT-to-client-context chain for a resource set given our same example, using the “uri” location property of the resource set description, which is optional and the only part of a resource set description that isn’t entirely abstract: If the RS registered the endpoint with some kind of query parameter on it identifying the RO, discoverability would be possible, at (what I believe is) the small cost of inventing a “new URL” just for the purpose of user discoverability but not real URI namespace management. Thinking about Twitter’s API, it would be possible to look up “Alice in Twitter”, “Bob in Twitter”, etc. in the directory and attempt access to their protected Twitter endpoints without inventing new API structure. If the RS and AS had the opportunity to extend the resource set description JSON structure for extra discoverability features, the RS could add a property for RO identity, enabling an out-of-band means for the requesting side to discover and convey RO identity in, say, a request body. If the RS registered only the generic endpoint, indeed discoverability wouldn’t be possible without a totally out-of-band RO hint provided somehow. If this thinking is correct, I think it would be a good idea to revise our wording because we were trying to signal something about the nature of the RS API, but backed off of it and — while making a potentially true statement about the client API call — overstated the case by getting into implementation detail (“the URI reference used by the client"). I suggest making the following revision: "Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource set identifier associated with that resource. If the interface presented by the resource server is not resource owner-specific, the client needs to supply sufficient additional context as part of the resource request. See the [UMA-Impl] for advice on ways to accomplish this.” …and then, obviously, adding something like the analysis above to the UIG. (Note that I call it “interface” and not “API” because we do that elsewhere in the spec; we don’t presume it has an API in the classic sense.) Thoughts? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 5

groundwork for non-vertical-specific legal use cases
by Dazza Greenwood 22 Aug '15

22 Aug '15

Some groundwork on developing legal use cases for discussion next week is forwarded below. More general background on the law of agency is available at: https://en.wikipedia.org/wiki/Law_of_agency ---------- Forwarded message ---------- From: Dazza Greenwood <dazza(a)civics.com> Date: Fri, Aug 21, 2015 at 2:59 PM Subject: Re: [WG-UMA] Reminder: UMA legal subgroup telecon 2015-08-21 To: Eve Maler <eve(a)xmlgrrl.com> Cc: Mark Lizar <mark(a)smartspecies.com>, Adrian Gropper <agropper(a)gmail.com> Following up: For the next meeting, it sounds like the question is: What 2 or 3 use cases would "flesh out the AS possibilities"? The essence of two distinct alternative possibilities we discussed are: 1) Its an AS world and Alice just lives in it; and 2) The AS works in Alice's Restaurant. Eve, as always, you posed a really good question and I'd be happy to work on it for input to the next meeting. My own instinct is usually to go into the weeds of fact specific contexts like in HIPAA or the EU privacy directive. But upon reflection I like your proposed next step more and more because it logically is the first brick of an otherwise uncertain foundation. Here is my thinking: Currently, most of the legal context and basis for establishing rights and obligations of parties using UMA will source from the economic sectors and verticals in which UMA is deployed and used. This however is complex and confusing to analyze. The focus for next week is therefor to develop use cases that are not vertical-specific to any particular vertical. This also means keeping identity-federation-agnostic. This is a narrow scope focused on identifying, describe and defining the "base-case" legal roles and rules between Alice and the AS. The fundamental assumption in Scenario A is that the AS "works for" Alice in the sense that it "serves the interests of" or "is answerable to" or "directed by" or "the legal Agent of" etc Alice in some meaningful way. Examples of these relationships between individuals and organizations include investment banks who transact money or other assets of an individual and law firms who advocate for an individual. Identifying the legal dimension of the use cases from the perspective of generic "agency law" would give us traction to make good progress on the task for next week. It is possible to apply the rules of agency law without reference to other more specific legal relationships arising from roles associated with any particular economic sector or industry vertical context. Applying the rules of agency law is one way to credibly address the question of who will prevail in a dispute between the parties over protected resources. That means it provides a basis for concluding what bundles of rights or responsibilities any given use case actor has with respect to the other actors and to the protected resources at stake with UMA use cases. For a sound legal analysis it is important to have a sense of the nature of the thing at stake. If is a family member we have one analysis (maybe we can limit their TV watching but not take their TV) and if it is a city we have another (maybe we can out it into receivership but not under occupation). The most relevant legal aspect of OAuth 2 (hence UMA) protected resources is that they are property. These resources are basic boring normal property. They happen to be intangible property and that has been normal and boring for decades. No big deal. The nature of basic property is not specific to the idea of "intellectual property". That is another context that may or may not be important or even apply to any given intangible property, depending on the context. What definitely applies and provides a direct, simple and complete cross-walk to regular old vanilla agency law and heaps of other well understood and widely agreed legal fact patterns is the fact that these resources are also property. There exists a long tradition of roles and expectations about property rights and all that can usefully be vectored directly into the equation for Alice. It may be helpful to connect the dots and make a clear surface area for application of things like business models, legal terms and technical protocols. Among other things, data and other protected resources like services or rights to service levels etc are also property and people have "property rights" to buy, sell and otherwise slice and dice property rights. UMA legal use cases that focus on the specific rights or obligations linked to protected resources are tractable and totally avoid the needless debates about what "ownership" does or should it could mean if only everybody would agree to that definition. The question of ownership has been asked in many a personal data and electronic transactions forum and it is very definitely the case that everybody does not agree on a definition of ownership. And yet, it is frequently possible to find agreement on named rights and obligations with respect to data and other property. The concept of ownership suggested it is the sum total of all rights to property. One could say that "exclusive control, possession and enjoyment" of property is full ownership. Yet, much of the value and fun of having data and other stuff comes from sharing it. Most people would not have a home if the value was not shared with whomever hold their mortgage. Who owns the home when the mortgage is worth 90% or even 110% of the economic value of the property? The deed would says title owner is Alice and yet the word ownership is not really very important to the practical questions of who can do what. The basic roles are Principal (which is a reasonable fit with with UMA's happy Alice and 29100 Principal as well), and Agent and Third Party. It is as good a starting place as any I can think of and better than most. The authoritative source of agency law is the "Restatement" and it is both a source of voluminous case law and also boasts a lot of law school and other pre-argued "fact patterns" with broadly agreed legal "answers" and reasonably expected dispute outcomes. The presence of a lot of well worn fact patterns based on generations of case law and codified/formalized rules (ie the "Restatement") is very valuable for the purposes of this workgroup. The value of such fact patterns is they are carefully designed in a way that can be cross-walked to technical use cases pretty easily, providing a source of existing agreed legal scenarios with named roles and expected legal results to get us started. Coming up with that stuff from a blank slate and getting broad understanding and agreement on the expected legal results can be a daunting long term task and therefore makes it less likely this legal group could achieve its adoption oriented mission. As a side-note, part of what makes the UMA flavored Alice to Bob flows interesting is precisely that they shed light on the nature of roles individuals have in relationship to "service" providers. There are many layers of connotation around the legal concept of a "service provider" and decades of law school text books and bar exam fact patterns that routinely position such parties as agents providing a service for or on behalf of principals. This gives tools for lawyers to deliberately structure transactions by defining defining roles and corresponding legal rules to create predictable and beneficial legal outcomes for their clients. By contrast, typically in the modern mass-market networked economy it is the individual who works for and is the legal "agent" of one or more organizations which are the legal "principal" in that context. These are legal terms that apply to the "roles" of the parties and from which "relationships" can be revealed. Employment relationships, as an example, carry some predictable sets of rights and obligations and also vary to some degree depending on factors like the applicable jurisdiction(s), and other relationships the parties may also have with one another or with others (like when somebody is your patient but also your boss or your student but also your auditor, etc). In doing an AS relationship analysis that "non-vertical-specific" we have an opportunity to start with a very clean slate and just ask the level-setting question: what is the basic legal relationship and which roles in the relationship is played by each "party" (aka actor or entity or person) identified in the use case? This is a great question to level set for the call next week and provides a sound foundation upon which to clearly layer vertical-specific relationships and other important sources of context. It is possible to identify, clarify and simplify the context of use cases by just naming the legal roles/relationships of parties conducting transactions or other interactions. Once the legal dimension of context can be refined down to a few defined roles and interactions it is a lot easier to speculate on and have an opportunity to successfully deliberately structure the relationships and transactions to achieve more predictable intended legal results. Layering on "vertical-specific" financial services, educational, clinical care, municipal, commercial, law enforcement, workplace, etc contexts will provide a well of known and named sets of legal relationships corresponding to definite and repeating roles which can therefor be linked to each identified party in any use case. Typically a technical use case provides to little information to assign vertical (or other) specific legal roles to a given party with high confidence. This is signaled when a lawyer says "it depends..." when asked what legal roles applies. That goes double for the evrn more ambiguous question "who 'owns' this or that data or other property" in a use case. The good news is that by at least by answering Eve's question about non-vertical-specific and then some vertical-specific use cases and developing some consistent documentation of roles and other terms we will have built a tractable legal fact pattern. With that traction we can make progress to resolve the key sources of ambiguity needed for lawyers to make conclusions like "in use case xyz, Alice is the Principal, the AS is the Agent of Alice" and "in use case abc the AS is a "covered entity" under HIPAA and has a legal obligation to share Alice's resource with Bob upon Alice's signed consent and request to share". This is good and such traction is one way to achieve the mission statement of this legal subgroups. When a lawyer says "it depends" the opportunity is to elicit the factors upon which a legal conclusion about the situation depends and therefor to structure (aka architect) systems, relationships and activities to get intended legal results. The opportunity this workgroup had is to surface the important and potentially outcome changing factors upon which legal determination of use case by use case roles depend. The purpose of creating a sound basis for assigning any/all potentially applicable legal roles to parties in use cases is chiefly to deliberately define and design the legal relationships, rights, responsibilities and results. Ok, so beyond writing a lot of blah blah words, here is what I can commit to for input to the next legal group meeting: I commit to publish a roles and definitions wiki page that is cross-referenced/cross-linked to the use cases we have so far and - more importantly - where the group can continue compiling named roles and other defined terms. Each term will be at an HTML anchor point to simplify and streamline identification of the meaning people are using and to provide a "ready to use" resource for popping in the eventual set of terms and meanings chosen by the group for use in a final set of legal use cases and corresponding recommendations. Thanks, - Dazza | Sent from my iPhone | Please Forgive Typos _________________ | Dazza Greenwood, JD | CIVICS.com <http://civics.com/>, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu <https://law.mit.edu/> | Me: DazzaGreenwood.com <http://dazzagreenwood.com/> | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface On Aug 21, 2015, at 12:01 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: AI: Dazza and Eve: Coordinate on producing 2 or 3 candidate distinctive use cases that flesh out the AS possibilities, non-vertical-specific and identity-federation-agnostic.

2 1

Fwd: [KI-LC] Of Possible Interest - OTA IoT Trust Framework Public Review
by Eve Maler 21 Aug '15

21 Aug '15

Here’s something called a “trust framework” that looks a bit different from what identity federation (or, possibly, access federation) folks might have in mind, but is very interesting. OTA does good work. If anyone is interested to reach out to them in a more formal fashion around UMA synergies, or would like to coordinate on comment collection, let me know. Eve > Begin forwarded message: > > From: Joni Brennan <joni(a)kantarainitiative.org> > Subject: [KI-LC] Of Possible Interest - OTA IoT Trust Framework Public Review > Date: 21 August 2015 at 12:26:51 PM PDT > To: "LC(a)kantarainitiative.org" <LC(a)kantarainitiative.org> > > Dear LC - the Online Trust Alliance has put out a IOT Trust Framework for public review. I believe the paper is 5 pages (for a send of the scope of review). > > OTA has invited Kantara to comment on the paper. > > https://otalliance.org/iot-trust-framework-submission <https://otalliance.org/iot-trust-framework-submission> The deadline is Sept 14th. OTA would be happy to provide your members a briefing or webinar. > > If WGs / DGs have particular interest we are happy to review organizational liaison opportunities as well. > > Best Regards, > > Joni Brennan > Kantara Initiative | Executive Director > email: joni @ kantarainitiative.org <http://kantarainitiative.org/> > > Connecting Identity for a more trustworthy Internet - Overview <http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351> > > > > _______________________________________________ > LC mailing list > LC(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/lc Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Greetings
by Nick Roy 21 Aug '15

21 Aug '15

Hello, UMAnitarians, This is a quick note of self-introduction. My name is Nick Roy - a few of you know me from InCommon stuff. I'm a technical director at InCommon, and I started working there in early June. Before that I worked in identity management at Penn State and The University of Iowa. I'm interested in UMA for a few reasons. We're looking at how it fits in to a consent manager that Ken Klingenstein is working on, and I'm personally interested in OpenID Connect for its usefulness in delegation, mobile apps, and API authorization. Best, Nick -- Nick Roy Director of Technology and Strategy, InCommon Internet2, Denver (GMT -6:00)

1 0

Text affecting #163 (public info), #164 (error code returned) -- and even #168 (ticket in JSON)?
by Eve Maler 21 Aug '15

21 Aug '15

In discussing how to implement our decision on issue #163 last week for how to add the WWW-Authenticate header to success responses in addition to error responses when the client presents no access token, we realized that: 1. The API correctly might want to return 300-class responses in addition to 200-class responses (that is, it’s entirely up to the API what “success” means for it). 2. As long as the response contains the WWW-Authenticate: UMA header and the relevant AS location and ticket info, we don’t much care what HTTP status code is used, because this is enough to tell the client what to do next. 3. If we broaden the text to allow any status code at all instead of 403, it’s sort of non-breaking (barring the “other responses by 403 are undefined” wording that’s in there now) — noting that this also allows a 401. (Hello, issue #164. :-) This resulted in the following wording: https://github.com/KantaraInitiative/wg-uma/commit/b784e6c33e45c02b267ad6b2… “It SHOULD respond to the client with a response that MUST include the "WWW-Authenticate" response header field with the authentication scheme "UMA", providing the authorization server's URI in an "as_uri" property in the header, along with the just-received permission ticket in the body in a JSON-encoded “ticket” property.” - What do we think of this wording? - If we like this wording or something similar... 4. Once we got to this point, I felt increasingly uncomfortable with leaving issue #168 to a later major version because of point no. 1. It’s crystal-clear that the API (which could just be a web app) might want to return a web page or a graphic or whatever. How do you return a JPEG along with a JSON body with a ticket in it? This issue seems not just “critical”, but “blocking”. The downside seems large, the upside seems large, and it seems like a low-impact change to the spec and implementations. The discussion in that issue seemed to be going in the direction of returning the ticket as part of the WWW-Authenticate header. - Are we willing to choose a “breaking” solution along these lines in the patch release? - If we’re not, would we be interested in a “non-breaking” solution along the following lines? “SHOULD provide the ticket in ticket=“ticket-value” in the header, or in the body in a JSON-encoded "ticket” property but the latter is deprecated”. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 6

Issues
by Maciej Machulak 20 Aug '15

20 Aug '15

Hi all, Since we have not covered all the issues today, I include links to commits. Some were not yet covered - e.g. 172. Please review if you have a chance prior to the next call. https://github.com/KantaraInitiative/wg-uma/commit/c66e54a2ff435d4f3c1c1d97… https://github.com/KantaraInitiative/wg-uma/commit/05461d2a45defc9c65c0e1b5… https://github.com/KantaraInitiative/wg-uma/commit/8b99c122a38779733101b06f… https://github.com/KantaraInitiative/wg-uma/commit/1196c74190c87a4dbb0597e8… https://github.com/KantaraInitiative/wg-uma/commit/5c76f22d043bc99109cfef53… Also 1 comment: https://github.com/KantaraInitiative/wg-uma/issues/146 Cheers, Maciej -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

1 0