- WG-UMA - mailman.kantarainitiative.org

Notes from UMA telecon 2016-01-14
by Eve Maler 14 Jan '16

14 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14 MinutesRoll call Quorum was not reached. Quick legal subgroup update The subgroup meetings are going to continue, and consensus was reached on releasing beta model text by the end of Q1. Update on AIs from last week Andi now has the data he needs for the blog post. We need to publish the specs first; that should happen tomorrow. Mike is doing a Kantara blog post <http://www.gluu.org/blog/gluus-rsa-conference-2016-events/> about RSA sessions, including those that relate to UMA (and beer!), and can mention others. Eve is doing a privacy talk with Josh Alexander (and they'll be singing again too [image: (smile)]). A good idea is to send calendar invitations to those you'd really like to come to your talk. Hopefully Kantara will be sponsoring the Non-Profits on the Loose party again at RSA! Keep on the lookout. Even if not, let's all try to get together and hoist an UMArtini (or something – or a BLT...). Thomas and Maciej and Eve are very close to finishing other AIs. Review roadmap use case/technical issue matrix (Eve AI) and figure out what to dive into/how/when in Q1 - - Good F2F opportunities? - Good liaison opportunities? - Charter AIs? We are looking for "customer need" for these use cases and technical issues. Let's put initials of participants where they can confidently express "customer need" in 2016 or 2017 (or, if you want to remain pseudonymous, get in touch with Eve and she will put XX in for your initials). use case technical issue IoTAPI securityfederated authz RS authorization discretion (also "legal"?) RO access limit discretion (also "legal")wide ecosystems (is this a meta- use case?) access federations ("legal") AAT burden permission reg extension MSclient-to-AS-first efficiency MSself-contained token validation RPT needs refresh token* Shoebox endpoint* An issue that Mike wants UMA to explore is the new NAPPS solution <https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00> being proposed that uses PKCE. It leverages new system browser capabilities to return control to a native app using a custom scheme that the native app registered. Could this solution be applied to how a client delivers an RPT to a mobile app? Since the client just makes a direct back-channel call to the RPT endpoint at the AS, is this needed? Perhaps not right now, but maybe this could be used where we use a redirect flow (redirecting Bob for claims gathering after getting need_info with redirect_user), or if we start considering an authorization code-type flow for a redesigned client interaction with the AS a la Justin's suggestion (AAT-free). Mike remarks that a self-contained token is interesting but may be a nice-to-have for him vs. a self-contained token. In the work he's describing here <http://ox.gluu.org/doku.php?id=uma:oauth2_access_management>, the client-to-AS-first pattern could be relevant. Adrian would like an RS to be able, based on jurisdictional requirements, to get hold of verified attributes of the requesting party. This likely goes beyond healthcare, he surmises. What happens if the RS trusts the AS to be the RO's agent but doesn't trust the AS to make proper authorization decisions on behalf of the RO (e.g., by assessing verified attributes presented by the RqP)? Currently UMA says that if the RS cares about such attributes, it can gather them locally; it doesn't (by default) get them from the AS. Are we interested to develop a token profile for this to come from the AS? Perhaps there's not enough impetus. What about a "Shoebox" endpoint? The AS could present this endpoint for more than "consent receipts" – importantly, notifications are a big part of many laws. It would be great to bounce this off our legal subgroup. Is it, in fact, right for the AS to take on such an endpoint? What "RO access limit discretion" means is that we want to set up a one-way valve. Currently the spec it's a MUST, but technically it's not possible to enforce that the RS not give access when the permissions in the RPT say "no" in a technical fashion. However, it may be possible to set up a conformance suite in such a fashion to catch such cases and force the throwing of an audit log entry. In fact, this could be a case where a "Shoebox endpoint" could be a key part of a technical solution, in that we could mandate notices for certain kinds of access given. *AI:* Eve: Put starred items in the left column into GitHub issues. AI: Eve: Post matrix in a more prominent wiki place and start to check off relationships among the columns and rows, and advertise the opportunity to state priorities. Attendees As of 18 Dec 2015, quorum is 6 of 11. (Evariste, François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. François 3. Domenico Non-voting participants: - Steve - Katie - Adrian - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-01-14
by Eve Maler 12 Jan '16

12 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14 Date and Time - *Thu Jan 14,* 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 - *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 Agenda - Roll call - Approve minutes of UMA telecon 2016-01-17 if quorum - Quick legal subgroup update - Update on AIs from last week - Review roadmap use case/technical issue matrix (Eve AI) and figure out what to dive into/how/when in Q1 - Good F2F opportunities? - Good liaison opportunities? - Charter AIs? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA legal subgroup telecon 2016-01-08
by Eve Maler 08 Jan '16

08 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-01-08 - Review proposed mission and timeline <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> - Review high-level requirements <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> - Review latest candidate model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> Attending: Eve, Ann, Jim, Adrian, Jon, Mark, Thomas, Bill Wendell (guest - ears only), Andrew Hughes, Sal Mission and timeline discussion A proposed mission and timeline were sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> . Jon speaks in support of the three goals. Is "model clauses" the right phrase, given that "EU model clauses" is something of a term of art? We're free to call it whatever we want. RoboClauses? [image: (smile)] Maybe the connection to EU model clauses is helpful to us. Regarding meeting scheduling, if text review is paramount in the early going, availability of interested parties is the most key. Offline review and reporting of comments by others could work great. "Model text" was Eve's temporary phrase covering not just the clauses but also the definition. "Model T – you can start with any color you want, as long as it's black!" We're thinking that the "standard" meeting time of Fridays at 8am PT would be okay for starters in working on the model text. Note that Eve can't make January 22, so maybe we can move or skip that one. Andrew's project is holding a F2F in January, and by February will possibly be really ready to need our outputs. Right now they're wrestling with different views on what "authorization" means. Is it authorization to release information? access to an API? (UMA would rely on the semantics of the API being protected for the definition.) Mark notes that consent and permission definitions should come into the picture as well. This does actually impact our term definitions because we use the word "Authorization" as part of our UMA role names, and so we may have to define Authorization, or at least define it in a limited sense so that a context in which the word is defined in a different sense is not incompatible or confusing wrt our usage. If there is, somewhere (EU?), a standard vocabulary, can we leverage it? Or is it too backwards-looking? Let's add this to our open issues. *AI:* Eve: Add model text issues to our issues backlog and tag them appropriately, including the issue of defining authorization, consent, etc. Consenus on the mission is positive. What should our timeline actually be? Jim recommends that we target a real version number of 1.0. We can achieve this sooner rather than later if we have real review by people who really need this text! Eve has been collecting external reviewer candidates. We did some more brainstorming. The right time for a beta version of the model text for review: end of March 2016. *AI:* Eve: Send continuing calendar invitations. Requirements discussion Some proposed high-level requirements were sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> . Eve did a quick reading of the proposed high-level requirements. People started dropping off, but it sounded like there was at least some weak rough consensus. [image: (smile)] We'll work with this list for now until it proves problematic. Draft model text The latest model text for review, with commentary, was sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/j5hKnR6VB…>. It lives persistently here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> . We took a quick look at the message sent out. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

[Legal] Model text for review
by Eve Maler 08 Jan '16

08 Jan '16

Rather than worry (for now) about the form of documents that use our model text, we thought we would home in on just the term definitions, abbreviation definitions, and model clauses -- what we're collectively calling "model text". We're only partway towards an editor's draft reflecting the feedback we gathered last time. Model text items needing review and work: - Term and abbreviation definitions (revised, and red taken off token names) - Multi-party conditions and duties to pairwise (partially revised) - Distinguishing between delegatable and nondelegatable rights and responsibilities (possibly leveraging CARAT <http://civics.typepad.com/files/carat_final_011400-1.pdf>) (not revised) - Considering the need for conditions subsequent - The need for clauses dealing with security layers underneath UMA (see issue notes below) - Considering issue notes sprinkled throughout existing clause text - ...? The link we'll use persistently for the draft model text needing review is: http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative… If you go there now, you'll see a kind of table of contents, with entries for 0.md, Candidate, Clause, Comment, Terminology, and Z. If you go into 0.md and click the Document link at the top, you'll get an expanded view of the model text. If you go into Candidate, you'll see a list of pairwise "conditions" that will help us explode our too-complex multi-party conditions to meet the goal we discussed last time for breaking down all relationships between parties into pairs. Here is the analysis gone through to get this set of conditions for a large subset of the existing clauses, namely the relationships among the Authorizing Party (Alice), the Authorization Server Operator, and the Resource Server Operator, which end up getting bound by a protection API token or PAT. (Note that the clauses exposed in 0.md don't yet list out "multi-conditions" yet.) Conditions (my names here were informal; Jim gave them slightly different names in the file and we can change them at will): - RSO-ASO role establishment: For the period that the Resource Server Operator and Authorization Server Operator have mutually agreed to serve in these respective roles for each other - RSO-AuthzP role establishment: For the period that the Resource Server Operator and Authorizing Party have mutually agreed to serve in these respective roles for each other - ASO-AuthzP role establishment: For the period that the Authorization Server Operator and Authorizing Party have mutually agreed to serve in these respective roles for each other Duties that depend on all three conditions (links here are to files linked off of 0.md's Source view <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> ): - (depending on what we decide regarding the discussion about respecting permissions) Duty.1 of AP_Delegate-Protection_0.md <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (probably modified to clarify that it reserves the right to apply its own local authorization processes) - Duty.1 of ASO_Register-Accurately-and-Timely_0.md <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (only to AuthzP, not also to ASO? why does it owe this to the ASO?) - (depending on what we decide regarding the discussion about respecting permissions) Duty.1 of Respect-Permissions <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> -- or maybe it will end up being Disallow-Access-On-Insufficiency or something - Duty.1 of Follow-Policies-Accurately-and-Timely <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (only for AuthzP, not also to RSO? why does it owe this to the RSO?) Continuing the exercise, we didn't give Introduce-Authorization-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> and Introduce-Resource-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>, respectively, the right condition because what precedes them is actually the process of the Authorizing Party consciously identifying which partner they want the other one to work with, not already having a valid PAT. So it needs to be something like this instead: Conditions: - ASO choice acceptable to RSO: When more than one choice of an Authorization Server Operator is acceptable to a Resource Server Operator - RS nondefault AS choice interface: When the Resource Server has presented an interface to the Resource Owner that does not default to an automatic choice of Authorization Server - RSO meets ASO client credentials requirements: When the Resource Server has met any requirements for acquiring OAuth client credentials - (maybe need other security precautions here, about OAuth redirects and registered callback endpoints? or can that be commentary?) Duty: - Duty.1 of Introduce-Authorization-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (probably reworded to be more formal) Conditions: - No preestablished ASO relationship with RSO: When the Authorization Server Operator has no preestablished relationship with the Resource Server Operator - RSO meets ASO client credentials requirements (haha, reuse again) - (maybe need other security precautions here, about OAuth redirects and registered callback endpoints? or can that be commentary?) Duty: - Duty.1 of Introduce-Resource-Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> (probably reworded to be more formal) Out of all the clauses originally written, this leaves only the following to be analyzed afresh. - Adhere-to-Terms in both directions - Supply-Truthful-Claims - Is-Legitimate-Bearer - Request-Limited-Claims *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-01-07
by Eve Maler 07 Jan '16

07 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-07 MinutesRoll call Quorum was reached. Approve minutes of UMA telecon 2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> , UMA telecon 2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05>, and UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> MOTION: Andi moves, Thomas seconds: Approve minutes of UMA telecon 2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> , UMA telecon 2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05>, and UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17>. APPROVED by unanimous consent. Briefly review upcoming meeting schedule <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> The Jan 21 WG meeting is canceled. The APAC-friendly fortnightly sync meetings have been rescheduled, starting in the last week of January. The legal subgroup will be discussing tomorrow whether to restart weekly meetings. Recommendation ballot passed! Status of publication of Recommendations and IETF I-Ds: We got *about* 25 Yes votes and no No votes – a healthy response. We're still working on publishing the new Recommendations. Regarding the email about the workflow for creating new Recommendations and drafts, Maciej has a new suggestion: creating new GitHub branches. It's a relatively infrequent step, though, so it may be overkill. He'll write that suggestion up. *AI:* Andi: We should do a Kantara blog post about the new Recommendations and maybe share how many issues were closed, the number of votes, etc. *AI:* Thomas: Create two new I-Ds, changed to Informational, for UMA Core and OAuth RSR, that just have abstract, first intro paragraph, and second paragraph that normatively links to the respective final Kantara Recommendation. Discuss candidate charter revisions and 2016 roadmap priorities based on proposed technical and legal efforts - See notes from UMA telecon 2015-12-17 and list discussions for proposed technical efforts – summarizing: - Use cases: IoT, API security (AS-RS tight), federated authorization (AS-RS loose), RS needs to apply mandatory access controls for higher "LOA", RO needs to preserve right of access (health context), wide ecosystems (health context), RO needs to ensure RS respects insufficient authorization data (health context/BLT dimensions) - Technical issues: AAT burden, multi-resource-set permission registration, client-to-AS-first efficiency, self-contained token validation (SCTV <https://en.wikipedia.org/wiki/Second_City_Television>!) - Also see issue backlog <https://github.com/KantaraInitiative/wg-uma/issues> - Proposed legal efforts are to be discussed more fully on Friday, but we can review Mike mentions token exchange of an RPT for an OIDC token. How do you bridge a client that has been granted access by an AS all the way to getting access to a UserInfo endpoint? The reason to do this is that the AS is in claims-gathering mode. This is the "wide ecosystem" use case/conundrum. Mike had started to sketch out a design for getting rid of permission tickets, and they may keep both, but he concluded "it's not UMA". :-) Other ideas that have come up in the consent receipt world: Extension endpoint for ingesting consent receipts (nicknamed "Shoebox" by Andrew Hughes). Adrian has advocated for an AS to add this type of endpoint. (It doesn't exist yet.) An exploration of UMA wrt blockchain could be worthwhile, for those who have an interest. (An early exploration happened here.) OTOH, it could be a distraction if we're not careful. Thomas points to this provenance-tracking work <https://hardjono.mit.edu/sites/default/files/documents/CommonAccord_Provena…> that he did with Jim H. This is a novel use of UMA combined with agreements and blockchain: UMA-protected agreement deltas that can then be put on the chain, which are thus nonrepudiable, and available for public inspection and third-party auditing (and mediation?) in case of dispute long after the negotiation stage (this is where chain vs. digital signatures are a win). AI: Eve: Present to the group next week a "matrix" that aligns use cases we've identified to date with technical "itches", for consideration as 2016 discussion topics for UMA post-V1.0.1 work. Don't tie us down to version numbers yet. We know we'll be working on the BLT spectrum. Attendees As of 18 Dec 2015, quorum is 6 of 11. (Evariste, François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. Domenico 3. Sal 4. Mike 5. Andi 6. Thomas 7. Maciej 8. François Non-voting participants: - Katie - Ishan - Jin - Jim Hazard *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Ideas for an UMA extension for shorter flow
by Mike Schwartz 06 Jan '16

06 Jan '16

Uma-tarians, Here at Gluu we've been trying to come up with some options for API access management that leverage our UMA capabilities, while reducing the number of steps associated with the permission ticket flow. We came up with three options: 1) Eagerly issue an RPT token with permissions for resource sets where all scopes are satisfied. 2) Create a new token which just has the expiration and a list of scopes. Something like: { "active": true, "exp": 1256953732, "iat": 1256912345, "permissions": ["view", "manage" ] } And then the RS can evaluate if these scopes are sufficient for access. Maybe this token can be called the EAT (eager access token) or the GST (Granted Scope Token). 3) The RS takes the token above, and uses the OAuth2 token exchange endpoint, (see draft: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 ) to swap out for a real RPT that specifies the scopes, or returns a permission ticket as normal if the scopes aren't suffcient. #1 has scale problems... especially if the AS has resource sets registered by RS's in many domains. It seems only appropriate for very small deployments in a single domain. #2 has minimal overlap with UMA. #3, I guess you have to wonder if it is really much better than the permission ticket flow. It moves complexity to the client, and in a best case, saves two steps (obtaining permission ticket, returning permission ticket). - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike(a)gluu.org

4 9

Report from the legal "sub-sub-group" / Agenda for UMA legal subgroup telecon 2016-01-08 / request for feedback
by Eve Maler 06 Jan '16

06 Jan '16

*Hello to all our legal eagles!* As you may recall, we wrapped up our 2015 work season with several things: - A walkthrough of some early candidate model text - A promise from me to present a proposed mission statement for a next phase of work - A one-time meeting scheduled for this Friday, January 8, at 8-9am Pacific to discuss Jim Hazard and I kept up a steady pace this holiday season, through thick wifi and thin. :-) We accomplished three things. 1. Tomorrow we should be able to share a *new draft of the model text* that takes into account most or all of the feedback we got in the last meeting for your consideration. We may or may not have time to delve into all of it, however, depending how the following other discussion items go. 2. We hammered out a *high-level set of requirements* to better guide our model text design, as follows, and would like to walk through this and get feedback: - For efficiency, security, and transaction soundness, we want to enable the benefits of DRY [Don’t Repeat Yourself] and reusability as we develop UMA model text - We want the agreement builders of today not to be cut out of the loop in achieving the first requirement - For efficiency, we want to focus our model text efforts on UMA access federation enablement - We want to provide a user-friendly online environment for reusing UMA model text - We want users to be able to incorporate other text they are certain to need in their agreements that also include UMA model text - We want users to be able to choose their own formatting in reusing UMA model text, to the extent practical - We want users to be able to choose their own punctuation, grammar, and language paradigms in reusing our model text, to the extent practical 3. Most importantly, I can present to you a *candidate mission, six-month timeline, and process* that I hope you will feel makes good use of your time and expertise. Please take a look and let me know what you think. I will also be reaching out to you individually. - Retain the UMA legal subgroup as a cohesive subentity of the UMA WG - Next roadmap period to focus on: *January-June 2016* - Next goals to focus on: - Quickly publish the draft model text for external review (target #DPD16, which is January 28?) - Quickly gather requirements for development of the environment for using the model clauses - “Accordioned” until we know the final answer on our available budget - Oversee and “guinea-pig” the environment development work - Propose to continue the subgroup meeting series for this period - Because the right contributors to these activities will largely be SMEs -- those with legal knowledge and experience - Stick with existing time slot or identify new one? - Start outreach to external reviewer candidates immediately ==== Date and Time - *Fridays,* 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 - *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 - Review proposed mission and timeline - Review high-level requirements - Review latest candidate model text *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2015-01-07
by Eve Maler 05 Jan '16

05 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-07 Date and Time - *Thu Jan 7,* 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 - *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 Agenda - Roll call - Approve minutes of UMA telecon 2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> , UMA telecon 2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05>, and UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> if quorum - Briefly review upcoming meeting schedule - Recommendation ballot passed! - Status of publication of Recommendations and IETF I-Ds - Discuss candidate <http://kantarainitiative.org/confluence/display/uma/Charter> charter revisions and 2016 roadmap priorities based on proposed technical and legal efforts - See notes from UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> and list discussions for proposed technical efforts – summarizing: - Use cases: IoT, API security (AS-RS tight), federated authorization (AS-RS loose), RS needs to apply mandatory access controls for higher "LOA", RO needs to preserve right of access, wide ecosystems, RO needs to ensure RS respects insufficient authorization data - Technical issues: AAT burden, multi-resource-set permission registration, client-to-AS-first efficiency, validation of self-contained tokens - Also see issue backlog <https://github.com/KantaraInitiative/wg-uma/issues> - Proposed legal efforts are to be discussed more fully on Friday, but we can review - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

APAC-friendly UMA sync meetings
by Eve Maler 05 Jan '16

05 Jan '16

Hi all, and welcome to 2016. :) I have just created a fortnightly event for the new series of "APAC-friendly" UMA sync meetings (starting on Wed Jan 28 US/Europe-side and Thu Jan 29 APAC-side), and added all the same people to the invitation who were on it before. Recognizing that some people who used to live in the APAC region no longer are, and that others who can't attend meetings regularly would like to take advantage of an occasional sync-up, wherever they live, I'm happy to adjust the invitations however you like. Just drop me a private note. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Can Web standards make mobile apps obsolete?
by Adrian Gropper 02 Jan '16

02 Jan '16

http://arstechnica.com/information-technology/2015/12/the-app-ocalypse-can-… It's fascinating to see how this well-done article completely ignores the privacy perspective. Happy New Year Adrian <http://patientprivacyrights.org/donate-2/>

3 4