Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Agenda

...

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.

...

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. (smile) 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 nowsuggests that the UMA testing platform could define a set of claims to test against — like “get an OIDC token from a known provider with a known email address”, pointing to a shared/test account. There appears to be interest in doing this. If the claim types are of wide enough interest eventually for actual deployment ecosystems, somebody could write up a claim profile for them.

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.)

...