- WG-UMA - mailman.kantarainitiative.org

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

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

20 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20> Minutes Roll call Quorum was reached. Minutes approval tbs Trust elevation TC writeup reviews and trust elevation/ABAC generally Andrew wants a half-page, and it's hard to keep it that short! Please review and shorten. Is the permission ticket an essential concept for trust elevation, or not? Step-up authentication is one mechanism; non-uniquely identifying, but nonetheless trusted, claims are another that seems special to UMA ("CBAC"). There's a conversation <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150810/0056…> going on about the role of software statements and OIDC in trust elevation. Mike has been following this. NIST has an ABAC "building block" under review; Bill Fisher has reached out to offer a conversation with UMAnitarians. Eve will coordinate. Restricting GitHub editing Do we need to worry about this? The upside is total IP protection. The downside is the pain of making all WG participants get GitHub accounts (a pain to the people) and become collaborators on the repo to submit GitHub issues (a pain to the repo admins). Current sensibility is positive. Legal subgroup report We've been in massive use-case collection mode. The APAC sync folks had interest and asked about the big thread. We hope to start mappings to legal concepts very soon. Andi expresses a hope that specific jurisdictional legal requirements won't impact the specs. E.g., US healthcare examples often don't apply to UK and Europe. Adrian would like to focus at some point on adoption strategy, apart from specific legal strategy. We can cast our eye over lessons learned and release strategy. Issue resolution work We cleared about half the outstanding items in the spreadsheet and in the issues list. AI: Maciej: Tweak spec text related to #147, #170, and #172, and close issues as appropriate. AI: Eve to send email to WG links highlighting newly proposed #163 text, which impacts #164 as well; WG to discuss before next week. AI: Eve to send email to WG discussion topic around #168; WG to discuss before next week. AI: Maciej, Eve, and Andi: Do issue assignments before next week. 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 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike) Eve Andi Arlene Mike Maciej Thomas François Non-voting participants: Adrian James Sarah Scott Jin George Regrets: Mark Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from APAC-friendly UMA WG sync 2015-08-20
by Eve Maler 19 Aug '15

19 Aug '15

Attending: Eve, Gil, Allan, Colin Agenda: - "The very long thread” on legal use cases Eve was driving at “negative use cases”, to get at the points where things go wrong and legal experts are needed. E.g., what happens if Bob gets access outside Alice’s stated policy? Mark is intending to map use cases to consent receipts. Adrian is keen to explore Alice-run/built AS variants. - UMA release schedule update We have all hands on deck for working on the patch release, and we’re on track for our stated timeline. We refactored the non-backlog issue list. - UMA Dev update Save the date: A kickoff call is planned for that WG on Sep 9 (in APAC time zones). - GitHub repo hygiene Eve is thinking about requiring collaborator status to submit GitHub issues (that is, “closing" the repo). Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0