Notes from UMA1 interop meeting 2014-01-14

5 views
Skip to first unread message

Eve Maler

unread,
Jan 14, 2014, 12:04:53 PM1/14/14
to uma...@googlegroups.com
Attending: Maciej, Eve, Mark, Roland, George, Mike

Joni is creating the new uma...@kantarainitiative.org list right now. These notes from this meeting, and interop discussions, should happen on the uma-dev list.

What is the purpose of the interop? Is it conformance, or inter-implementation interop? Eve suggests it's for the latter, and also improving the spec to promote easier interoperability. Formal conformance testing could come later. There's a secondary purpose, of course, in encouraging more implementation and adoption.

Roland has begun work on an interop test suite, which we're excited about because we've seen the value at the OpenID Connect interop testing table. His suite for OpenID Connect does some screen scraping for the manual UX parts; this includes a script that can be run from a command prompt to simulate the human user, browser, and RP, and handles all the redirects etc.

We reviewed the current state of the http://tinyurl.com/uma1iop set of wiki pages. Maciej and Eve edited them a bit over the weekend.

The Results information is now separated into a separate page. The process of filling it out is still manual, though we anticipate that it's still easier to use than the OSIS method.

The Participants page has simplified the information that we require from every participant in order to get the testing going. One question is what API at the RS is being protected. Should we use http-json-resource (http://tools.ietf.org/html/draft-pbryan-http-json-resource-03)? Should we use a simple file-sharing API, e.g. getting a file to download? Or an OpenID Connect identity API, or FHIR? Or simply publishing whatever API in each RS's case, and offering an SDK for integration to it?

Mike points out that it would be useful to document the policies behind a set of resources, so that we can test that access is correctly given or not given. Roland's test suite will want to know what policies the AS is setting for each resource set registered.

And we also need to know how we're going to get requesting party claims in order to test for policy-matching. Should we exercise the OpenID Connect claim profile, which nominally requires a human "Bob" to get redirected over. Gluu has a web GUI for its test RP, and it's a challenge to keep up to date. Should we drive the interop parameters with the AS at the head? Whatever scopes/permissions/policies the AS entities can handle would dictate what we test.

Because UMA has the AS with two server-side interfaces (protection and authorization APIs) and the RS with one server-side interface (its proprietary API with UMA protection), how do we test all this in practical terms? What if some participants don't try and interop everything?

Netting out suggestions for info the participants need to supply in addition to what we've listed so far:

- Scope/permission/policy capabilities (AS only)
- Which subset of feature tests you intend to test for each role, if not all the tests
- Which profiles each role supports, and which scenarios this supports

What if we decide on some simple non-claim-dependent policies at a minimum, such as "only during the first 30 minutes of every hour and not during the second 30 minutes"? This would let us look at logs and determine if the access is given correctly. We also need a resource that's not UMA-protected at all. And then we could test a claim-dependent policy such as "an RqP with email X but no other email can get access", and even add a simple means of testing the authentication context leveraging the acr and amr properties in OpenID Connect's ID token (Mike's third-party profile is here: http://ox.gluu.org/doku.php?id=oxauth:uma_profile). Testing trust elevation would be a great way to educate people on what UMA can do.

Mike suggests that it would be simpler if we used a scenario where the client is already an OpenID Connect RP, and to which the requesting party has already logged in. In this simplified case, the client is capable of passing claims (which it already has access to) along to the AS.

Eve asks if we should rename the one claim profile we have, since we obviously could define additional OpenID Connect-related claim profiles (such as client=RP above).

We agree another one or two meetings should be sufficient to work through the remaining issues.

Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
Reply all
Reply to author
Forward
0 new messages