Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

UMA Dev telecon 2015-09-08

Date and Time

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.

Questions:

  • Modularity of Core vs. RSR?
  • 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?
  • Are we delivering auxiliary developer resources along with FOSS, such as the unirest.io website?


Attendees

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

  1. Eve
  2. Allan
  3. Roland
  4. Maciej
  5. Sal

Non-voting participants:

  • Jamie
  • Katie
  • Colin
  • Rebecka

 

  • No labels