Our next call will be at the APAC-friendly time.
Quorum was reached.
MOTION: Andi moves: Approve the minutes of UMA telecon 2015-05-28 and UMA telecon 2015-06-04, and read into the minutes the notes of UMA telecon 2015-06-11. APPROVED by unanimous consent.
Kantara's work streams are increasingly significant. The two streams are Connected Life (where UMA sits), and Trust Services. The IRM and Identities of Things work streams are very cool, and Consent Receipts has major synergies with our work. The presentations were of high quality. Links to materials are coming soon. Eve gave an UMA wireframe demo using a "connected car" use case. The Twitter stream from the plenary is here.
Since the last time we talked about this, the OIDC test suite actually launched. Thinking in terms of all of UMA, OIDC, SAML, and OAuth, it's useful to come up with a lowest common denominator. Roland has in mind a common platform, with branches that are specific to each of the four. In the last week, he's been preparing a new version of the OIDC suite – "V2.0". He'll be ready to move to the other protocols soon. A SAML project is getting going, with Internet2, the Austrian government, and others contributing to the costs. The actual writing of the test suite is less work than test design and result interpretation. Rushing to implementation may almost work against our goals.
Since a standard is written in natural language, a test suite "of record" ultimately becomes kind of a harder-edged version of the spec because it's machine-readable. It's "the spec" as far as implementers using the spec are concerned. Our goal is not to do what the OIDC conformance test suite developers did in a few cases, which was to make the test suite tighter than the specs. If we find any deltas in interpretation that require changes to the spec, we will go through the appropriate process to change it. But our goal is consistency.
How should we prioritize? What entity/ies should we test first? The AS is the target Roland and Eve were thinking of first. The RS is perhaps another candidate since it's server-side, though it shares the problem that OAuth has always had regarding interop testing, in that most of its interface is entirely unstandardized.
The earliest stuff in the spec is the "least interesting" from an UMA perspective. But the most core UMA stuff needs tester intervention. This actually gets into the question of natural variability of use cases that exercise different options in the spec, such as claims-gathering from human requesting parties vs. autonomous web service clients. Could we use "profiles" to distinguish these for testing purposes?
Justin suggests standard sets of attributes a la OIDC for UMA. Mike points out that the OIDC claims are LDAP-unfriendly due to their use of underscores. Eve points out that OIDC claims are available for standardized exchange in UMA today. So are we interested in a interop testing profile so we can just "get on with it" as an interop simplifying assumption? It sounds like that's where our heads are at for now.
Does it make sense to bat around a single test (or test of related tests) on email? There are no juicy in-person opportunities coming up until IIW, by which time we hope to have a test suite ready to try out. Here's how spec references might look, in the form of the emerging OIDC RP test suite. (The OP tests didn't have this, and it led to endless queries.)
August/September will be the active test suite development period for the WG.
As of 11 Jun 2015, quorum is 8 of 14.
Non-voting participants: