[WG-UMA] [Uma-dev] Feature Test review, some thoughts

Mark Dobrinic mdobrinic at cozmanova.com
Tue Aug 5 04:35:43 CDT 2014

On 01/08/14 18:14, Eve Maler wrote:
>> * access
>> FT-unprotected-resource : maybe loosen to be optional?
> Hmm. This just requires the RS not to "pollute" the response on a non-UMA-protected resource with UMA stuff. I could see how this is more like a definition of an UMA/non-UMA dividing line than an UMA-specific interop test. Is that what you're thinking in suggesting that it's optional? E.g., if some product were to fail this test, would we think this makes it less UMA-conforming? Maybe we should strike the test altogether, if the answer is no.

As I think your point also makes sense, my reasoning is more analytic in
the sense that: if an RS responds with (correctly formulated)
UMA-related parameters, this should have been captured in at least one
other test-case.
The specific test could be read as: ensure that the RS is not doing
anything that is not according to UMA, but those criteria are nowhere
explicitly specified, and as such no client *can* pass such a test.

Maybe it's indeed better to strike it as such.

>> FT-rs-respect-authz : consider adding in the description that this
>> depends on non-UMA specified API and scope usage, specific to the RS. To
>> stress that this test is impossible to specify from the UMA perspective
>> alone.
> Good idea. Are there any other tests where such a note would be useful? (I wonder if this sort of thing would be helpful to share with the folks who tried to start the OAuth interop testing conversation at IETF.)

I think most cases are covered pretty well by the UMA spec, but the
Client-RS communication allows for RS-specific API freedom.

It seems that the FT-rs-insufficient-authz test is the inverted version
of the FT-rs-respect-authz test, and as such could also use that same note.

OTOH, reconsidering whether scope should be downplayed: the RS *does*
specify what is sufficient, as it registers the "sufficient" permissions
with the ticket. So it would only depend on non-UMA specified API usage,
specific to the RS.

I have no idea about the OAuth Interop agenda, but I can see this
overlapping, as there is no OAuth specified API format.

>> General: about terminology, 'permissions' and 'authz' are used
>> interchangeably. Is this correct and desired?
>> i.e. "FT-rs-insufficient-authz : RS responds to client bearing a valid
>> "bearer" profile RPT that has insufficient permissions ..."
> Good point. Maybe we need a generic authz test, and then tests that are explicitly bound to RPT profiles that could be more specific. That way, communities that identify specific profiles can most easily "inherit" the specific tests, while the generic tests still give coverage. Any chance you can take a look to see how this might fly?

I was just pointing out the choice for which words to use here actually;)

As it stands now, I think specifying "just" the RPT Bearer profile is
the way to go, as this is what UMA 1.0 is about (and UMA-interop tests
should not be made more complex than they already are!)



More information about the WG-UMA mailing list