UMA Dev telecon 2015-09-08

Date and Time

Tue Sep 8 1pm PT / 4pm ET / 9pm UK / 10pm CET / Wed Sep 9 1:30am IST / 8am NZ (full time chart)
- Voice: Skype: +99051000000481 or US dial-in: +1-805-309-2350 (more options), room code 178-2540#
- Calendar: http://kantarainitiative.org/confluence/display/umadev/Calendar

Agenda

Welcome and convening the WG
Roll call and introductions
Leadership team nominations and elections
Charter review and discussion
- Deliverables
- Processes
- Meetings
- Contributions
- Liaisons
- Interop
- Other
AOB

Minutes

Welcome and convening the WG

Sal mentioned that there are other related groups at Kantara, including IRM and Identity of Things.

Roll call and introductions

Quorum was reached.

Leadership team nominations and elections

Chair and vice-chair roles? Two leadership team members is essential; three is even better! The Kantara Federation Interop WG has three, we believe.

Nominations: Eve nominates herself for chair. Allan nominates himself for vice-chair.

MOTION: Maciej moves: Elect Eve as chair and Allan as vice-chair for the next year. APPROVED by unanimous consent.

Deliverables

Allan describes his thoughts:

UMA has a pretty reasonable RESTful API, with the authorization server doing a lot of the heavy lifting. What would facilitate a "no-brainer" set of libraries that a resource server could use and connect up to?

The conception for resource servers is an open-source RESTful library that has an API (generic), a dozen methods, and implementations of those methods in the popular languages that people are interested in. The basics would be for registering resources, sharing resources, checking access, etc.

Sometimes the resource server is colocated with the client. When it's not, having a separate library for the client (as above) would be good.

To what extent would we add to the already-available UMA methods? There shouldn't be a lot of need for this, but getting rid of basic serialization and such would be handy. So, e.g., the "Create" method in the Resource Set Registration spec would become wrapped with a call that handles all the exception handling and such to make it easy-peasy.

His vision is to "UMAnify" something like the unirest.io libraries. There are two branches of this: Present developer tools akin to that website, and integrate UMA capabilities into existing client libraries.

Jamie comments:

RSR is a separate spec, so keep that in mind. The authorization check is separate. The resource ID is very important to hang onto, along with the various tokens, so we need to think about how much the libraries would do this management.

JAX/RS filters could make it challenging to integrate into other client libraries, so the "UMAnification" goal could impact the choice of frameworks for library implementation. But hiding exceptions and such is still providing great value.

Roland comments:

What about the API between the client and the resource server? How can we find a common denominator? (Eve notes that the V1.0.1 patch release of the UMA specs has slightly messed with exactly this interface, so we should pay attention to that.) For example, the UMA WG had discussed, for testing purposes, a simple REST interface that we could target? When we discussed a "test API" for a resource server, we considered the https://tools.ietf.org/html/draft-pbryan-http-json-resource-03 spec (now expired). But a more modern example might involve a Docker image.

Logging transactions would be a useful thing for the libraries to enable, so that developers could test that they integrated it right.

Katie notes:

Integrating the test suite could be useful, and providing a starter API could be helpful too.

Questions:

How to handle modularity of Core vs. RSR functionality?
Where does storage of key artifacts live: library or underlying app?
Do we have a design principle to minimize/maximize convenience API calls?
If we were to "UMAnify" (integrate UMA info) existing client libraries, which would be targets? and how should we prioritize development framework selection?
Are we delivering auxiliary developer resources along with FOSS, such as the unirest.io website?
What would we document the target generic API in? It may not matter...
Is it possible to serve test suite purposes alongside developer enablement purposes? What would have to be given up?

Design principles

Our overriding concern is to enable developers and give them the resources they need to be successful. We might have secondary goals as well, as long as they can be accomplished naturally and aren't antithetical to the main goal. A test suite alongside the client libraries seems to be one.

Logistics and next steps

How do the people in Europe feel about the time we picked for this meeting? It's not too horribly bad. It's more valuable for us all to be on the calls together, vs. splitting them.

AI: Eve: Book this hour weekly for "a stretch of time" until we are happy with the design of the generic API.

AI: Allan: Propose a draft generic API, by reference to Jamie's and Roland's work.

What about code contributions? We have to figure out how this will work.

Shall we use Kantara's GitHub area? Yes.

AI: Eve: Set up a repo for the WG to use, and set up the appropriate LICENSING.md and CONTRIBUTING.md files.

Attendees

As of 2015-07-31, quorum is 4 of 6.

Eve
Allan
Roland
Maciej
Sal

Non-voting participants:

Jamie
Katie
Colin
Rebecka

Browser not supported