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

Maciej Machulak m.p.machulak at newcastle.ac.uk
Thu Jul 14 13:38:22 EDT 2011


Hi,

Some minor comments inline:

>http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-07-
>07#UMAtelecon2011-07-07-Coreprotocol
>
>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!

+1 on using github for issue tracking.

>	Eve
>
>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?

Comment to the last paragraph: I think the requester can, indeed, change the names very easily. One option that we considered here in SMART is that the requester is also 'dumb' about claims and really redirects the user to the AM where the AM presents the information to the user as the only application. This information would contain the list of necessary claims. This would possibly solve the problem that you describe. Also, it would allow the requester to implement less. Instead of communicating to the requester that there is a need to submit an ">18" claim, the requester could also redirect the user to a page at the AM where such claim would be requested.

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

It's fine with me. It's just a nice feature to have and I'm sure SMARTAM proves that in some sense.

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

+1 on 'picking a horse' :)

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

Just to clarify, we would then differentiate between "create" and "update" based on the "If-No-Match" and "If-Match" headers?

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

Yes, and I think we discussed that at some point. If the AM is to send notifications to a host then it should have a key/token/whatever that would allow the host to authorize these requests. I think the general comment was to keep the host simple and have this relationship between host<->AM unidirectional (i.e. only the host has the token).

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

That sounds great. We also hope that SMARTAM will be used by more umanitarians and other Web users so that we can learn and communicate feedback to the group :-)


Cheers,
Maciej


More information about the WG-UMA mailing list