UMA Dev telecon 2015-09-08
...
- 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?
...