UMA telecon 2014-04-10

UMA telecon 2014-04-10

Date and Time

Agenda

  • Action item review
    • Zhanna: Jeeves?
    • Maciej: Claim profiling spec?
  • Interop and event planning
    • Any IDESG or other past-event news?
    • IIW
    • EIC
    • IRM
    • CIS
  • Webinar planning
    • Date: June 19, 8-9am PT
    • Theme: UMA, OpenID Connect, and personal data stores
    • Key participants: Maciej/Cloud Identity, Thomas/MIT-KIT, Dazza/MIT; who else?
    • Sponsorship interest?
  • Claim profiling work
  • Core spec work
    • Configuration data declarations of MTI features used alone and with additional profiles
    • Other issues on GitHub
  • RSR work
    • Complex resource sets and scopes
  • AOB

Minutes

Action item review

Zhanna has arranged for the Jeeves creator to come and speak to us in the next telecon.

Maciej will revise the claim profiling spec for the next meeting.

Interop planning

Some implementors are starting to fill out the participant tables. Note that Roland is leveraging the "pbryan" API, a simple RESTful CRUD API that uses JSON for all the payloads. Another interesting API we hope to use eventually is FHIR, which Jin's team has been examining.

Event planning

We haven't heard anything about the results of the recent IDESG meeting.

Maciej and Roland spoke at the Internet2 Global Summit this week, and the response around UMA was very favorable. Maciej's slides are here.

Quite a few people are attending IIW and surrounding events.

EIC will have a Life Management Platform talk from Domenico and Maciej.

The ForgeRock Identity Relationship Management Summit in June will have a Kantara workshop, at which Eve is likely to present.

A number of us may attend CIS.

Webinar planning

  • Date: June 19, 8-9am PT
  • Theme: UMA, OpenID Connect, and personal data stores
  • Key participants: Maciej/Cloud Identity, Thomas/MIT-KIT, Dazza/MIT, and Nat so far
  • Hashtag: #UMApcloud

We're still waiting to hear about sponsorship interest.

AI: Eve: Schedule a planning call in early May.

Core spec work

We discussed the issue of whether and when to require, allow, or disallow declaring mandatory-to-implement features in the AS configuration data. It's valuable to have a principle for this because we may run into the situation again, and we already have several situations to deal with. It's potentially more efficient to enable the AS to leave out a value when it's the only option and it's required, but it's also more consistent to always require an AS to declare everything relevant, even if a particular feature is required for a conforming AS to support. Since no other entity is required to consume config data at the moment anyway, the consequences are relatively low regardless. We didn't decide, but started to get a potential preponderance of support for requiring declaration of MTI values.

In the course of this discussion, we discovered that it was an editing oversight prior to the publication of rev 09 that led to the omission of mentioning authorization_code as an MTI grant type for PAT and AAT support. We could go either way in considering how to fix this: keep it not required, or add it back as a requirement. The authorization_code flow is the most secure, but some environments may not be able to use it. Jin had asked Dick Hardt once what his biggest regret was in OAuth 2, and his answer was the implicit flow. We didn't decide, but started to get a potential preponderance of support for adding back the requirement.

Jin pointed us to the Common Consent Framework and Thinktecture, one of whose principals has been, we believe, engaging with UMA folks on Twitter.

AI: George?: Analyze this framework wrt UMA.

AI: Jin?: Reach out to Dominick Baier re UMA.

AI: Eve: Add these two issues to GitHub.

Complex resource sets and scopes

 We discussed how the Personal Cloud Application Architecture discussed by Phil Windley (and the similar unhosted.org effort, which is more related to cloud storage than APIs) might impact or be impacted by the UMA model. Eve and Phil recently discussed it and potential OAuth/UMA implications of the PCAA's requirement to "mash up" APIs just to get access to data. We discussed how linking graphs employed by XDI and the Pico model could be an alternate way to negotiate terms of authorization with requesting parties/clients, and also could be a potential way to solve our complex resource sets/scopes challenges.

AI: ?: Look at PCAA?

Attendees

  • Eve
  • Mark
  • Thomas
  • Maciej
  • George
  • Jin
  • Zhanna
  • (may be missing some due to note-taking snafu)

Next Meetings

  • Focus meeting Thu Apr 17 8:30-10am PT (time chart)
  • All-hands meeting Thu Apr 24 8:30-10am PT (time chart)