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

Paul C. Bryan pbryan at anode.ca
Thu Jul 14 14:01:27 EDT 2011

On Thu, 2011-07-14 at 18:38 +0100, Maciej Machulak wrote:

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

Sure, such a page may request a ">18" claim, but how will the average
user go about actually fulfilling it? I'm of the opinion that claims
request/response is too complex for my mom. She needs agent(s) that do
her bidding. She also doesn't do crypto herself—the chip in her smart
card does. She trusts it. In a sense, it is her agent. So is the PIN pad
sitting at the checkout counter at the grocery store. So will her
smartphone with NFC—when she gets one.

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

Assuming that concurrency control is mandatory—which for UMA, I would
recommend, then…

Here is a create operation:

        PUT /some/resource
        If-None-Match: *

Here is an update operation:

        PUT /some/resource
        If-Match: the-current-ETag-of-the-resource 

> >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
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20110714/4a78131e/attachment-0001.html 

More information about the WG-UMA mailing list