[WG-UMA] Notes from 14 Jul 2011 issues discussion with Paul B.

Eve Maler eve at xmlgrrl.com
Thu Jul 14 13:05:33 EDT 2011


Thomas-- Paul suggested that we simply use github for issue tracking. Shall we do that? And can you incorporate the notes below into whatever version of issue-tracking you've done? Thanks!


Issue #14:

Since the operation being asked for is not "safe", it shouldn't conceptually be a GET; it should be something like a POST. An intermediary seeing the GET might give you unexpected behavior. If a system pre-fetches GETs to increase performance, that would have a side-effect.

A factor we haven't considered yet is the nature of the resource being protected. Often, it will be something that the browser doesn't consumer, but will need to be consumed by a specific kind of user agent. (Which might sometimes be JavaScript running in the browser.)

When the requester is a web app (like Gallerify.me), then it's not operating through browser redirects, right? It intercepts the resource and displays it to the user however. If there are checkboxes for the requesting user to check, then the requester web app is the one presenting those. Is there a security problem with the requester app potentially being able to modify the "display names" of the requested claims that need user agreement? Is this the equivalent of trusting the PIN pad (or even the waiter) at the restaurant when paying for dinner?

Issue #24:

Paul likes the idea of providing a policy redirection URI back to the host when it does resource set registration operations. Presumably the reason the AM returns the resource set ID is so that the redirect process can configure the AM to come up with that setting panel immediately once the authorizing user logs in.

Paul agrees with this being an optional feature in the core, meaning that it's optional for the AM to supply this info and also optional for the host to do the redirect.

Issue #15:

Claims-requested and claims responses flow "backwards" over HTTP. If the requester submits a request for authorization (let's assume in POST form for now), the AM would come back with an HTTP response of one of three types. The AM could support more than one claims format, so this seems like a case of content negotiation.

Content-type is meant to be used on an actual response or request message. It indicates the actual media type used in that message.

Accept is used by a user agent, to indicate what MIME types are acceptable in the response back to it (to negotiate the Content-type coming back). It can express them in precedence order. The general tenet is to be "liberal in what you accept".

Paul would like to "pick a horse" and pick some kind of content type for claims that is mandatory to implement. If we want to pick Claims 2.0 to cover lightweight claims for starters, we should really try to rationalize it onto JWT/WOES/JOES (new name!) so that we can leverage the "winning" token signature and encryption method.

We should be clear that the list of supported claim formats in the AM metadata is entirely extensible. We might list some candidate mandatory-to-implement ones, but it has to be possible to add your own. Should any names not dictated by our spec start with "X-" or "x-"? Yes.

The right answer for this actual issue should be the HTTP error code for when a server doesn't understand and can't produce the requested "Accept" type that the requester sent it. This is HTTP 415: Unsupported Media Type. Do we also need an UMA-level error? Probably.

Issue #25 and issue #27:

Paul has built backwards compatibility for POST-based creates in some APIs he has developed, but for our case, he thinks PUT is fine. For our Create method, he recommends requiring an ETag on it: "If-No-Match: *". We should require ETags throughout the usage of the resource set registration API. This way, you'll always say what you mean and mean what you say, and we don't have to worry about the circumstances Lukasz brought up.

In Paul's own APIs, he allows ETags to be optional, but if a server responds with ETags, then the client side is required to use the If-Match and If-No-Match constructs.

Issue #37:

We could just say explicitly that we are using HTTP semantics for Cache-Control, Expires, and No-Cache for scope descriptions and token status descriptions. We may want to say also that a host MAY explicitly refresh a cached token status before failing outright.

The downside to caching is that, unless there's a way for an AM to send synchronous notifications to a host that a token's status has changed, you have some latency in authorization ability.

Ultimately, we might want to start up a "best practices" writeup for AM implementors to discuss the tradeoffs in managing token status description caching, access token and refresh token validity periods, permission validity periods, and (eventually) the use of structured/meaningful tokens.

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

More information about the WG-UMA mailing list