Continuation of UMA Implementors’ Meeting
Session Topic: Open UMA Implementors
Wednesday 4A and 5A
Convener: Eve Maler
Notes-taker: Eve Maler
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
All of the current interop testers were represented in the meeting (Gluu, ZXID, Cloud Identity, Roland Hedberg), along with other in-process implementors such as Intel and ForgeRock. We discussed the current state of the interop testing, reflected here:
We took a look at the somewhat volatile state of the UMA core spec as we do issue burndown, reflected here:
http://docs.kantarainitiative.org/uma/draft-uma-core.html
We discussed the opportunity to develop a Best Practices for Implementors document as an adjunct to normative spec text, which could capture advice such as:
"You may want to use different OAuth grant flows for different use cases in minting protection API tokens (PATs) and authorization API tokens (AATs). For example, when the resource owner is an organization and not a human being, the client credentials flow (where there is no human user) may be appropriate."
We discussed the parameters of the type of interop testing we're doing at this stage. We agreed that we're doing "implementation" testing vs. "deployment" testing, meaning that we're okay with developing test instrumentation that accepts automated testing flows vs. requiring a human being to "babysit" testing flows to, e.g., press a button during key rollover etc. We discussed possibly allowing an RS to pass some version of authorization policy to the AS during resource set registration, not for the purpose of interop-testing the policy, but just because it's necessary to provision relevant policies to an AS to let downstream interop testing take place. There are a number of ways to do this. We discussed, but didn't fully settle on, a way to have the AS simply return a "yes" vs. "no" answer to a policy question.
We discussed the current state of user authentication. Roland's test suite currently handles all of the following methods: 1) username and password (for easy form automation), 2) token authentication (for easy query parameter automation), and 3) social login. We toyed with asking him to support JWT authentication in addition, but decided not to push our luck. :-)
A diagram we returned to over and over was this one, shown on the UMA wiki ( http://kantarainitiative.org/confluence/display/uma/Home ):
http://docs.kantarainitiative.org/uma/three-phases.svg
We annotated it during the course of the session, as shown in the attached photo:
