ADHOC: UMA Interop Testing Session Thing

Session Topic: Ad-hoc UMA Interop Testing Session

Wednesday 2J (K)

Convener: Mark Dobrinic

Notes-taker(s): Mark Dobrinic

Tags for the session - technology discussed/ideas considered: UMA, interop

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Session should make first attempts at introducing one UMA-role with another.

Interop specifications are being written, and can be found at http://tinyurl.com/uma1iop

The purpose is to see what to do to setup an interop test for an UMA Resource Server. For this, relations with an UMA AS and a UMA Client must be setup. The configuration of those roles must be identified first.

Next an explanation of the big UMA picture took place, to zoom in on the actual context of testing an UMA RS.

Based on the UMA big picture, discussion took place of different problems that can be covered by an UMA infrastructure.

One problem of interop testing with UMA, is that the API that the RS provides to a Client, is NOT standardized by UMA. This is recognized by UMA group though, so testing there is done not based on an API, but should be done by other validation rules.

In the discussion, it also came up that the concept of a Resource Scope in UMA is not the same as the concept of a Scope in OAuth or OpenID Connect.

To bootstrap: RS needs info about the AS, and AS needs info about the RS (either statically, or using Dynamic Client Registration).

Next steps for RS testing are to fork Roland's OAuth Authorization Server and make the tweaks (meaning: support the predefined PAT-scope) for UMA compliance. Build as much on top of existing OAuth specification.

We'll be taking it from there!