[WG-UMA] Notes from 13 Apr 2011 ad hoc meeting

[Eve Maler]

See also:

- Etherpad: http://openetherpad.org/uma-am-host-flows (topmost section, reproduced below)

- Current core spec: http://mrtopf.clprojects.net/uma/draft-uma-core.html

- Scoped access flow charts: http://groups.google.com/group/kantara-initiative-uma-wg/browse_frm/thread/69da3dbb28027acb

We got through maybe half of the possible message flows. Please feel free to comment directly in interspersed fashion below, and we'll pick the thread up again in tomorrow's call. Thomas, you nominally have an action item to turn this into spec text, and I'll call upon Paul as well if he feels the pull...

Eve

Discussion from 13 Apr 2011 ad hoc meeting:

Attending: Eve, John, Frank, Maciej

Different flow subsets we have to cover:

• (Precursor in step 1: Host-AM introduction by user, such that the host gets an access token)

• ISSUE (high-prio): It's time for us to finish solving the means by which AMs and hosts work out which sorts of access tokens they deal with.

• (Precursor in step 1: Host-AM protected resource registration, already defined in separate spec)

• Host-AM token validation

• Assumptions:

• The host can disambiguate from the nature of the requester's access request which of its users has "domain" over the resource requested

• ISSUE (high-prio): How bad is it that a lot of popular protected APIs rely solely on the client's/requester's access token to disambiguate which user's stuff access is being attempted on? More on this below.

• Request message type: POST?

• Inputs that the request message has to contain:

• Host's access token (has two purposes: authorizes the host to use the AM's token validation endpoint and uniquely identifies the user they have in common, allowing the AM to look up the right user policies and resource sets/actions)

• Requester's access token (the thing to be validated)

• Endpoint: AM token validation endpoint (meant only for hosts to use; advertised in its XRD)

• Outputs that the response message has to contain:

• UMA error (HTTP success): token invalid

• ISSUE (low priority): sub-error messages about type of token problem: malformed, stale, requester's access token is for a user at this host that doesn't match the user associated with the provided host's access token (the "this isn't even wrong" error :-)...

• UMA success (and HTTP success): token valid

• Along with scope manifest (which may be empty)

• Host-AM scope request registration

• Assumptions:

• The host is able to make a judgment about what scope of access the requester is seeking based on the access attempt

• Request message type: PUT?

• Inputs that the request message has to contain:

• Host's access token (has the same two purposes as above)

• A reference to a previously registered resource set ID and one or more actions that apply to it, which a particular requester is (in the host's estimation) seeking access to

• The requester's access token that was present in the access attempt

• Outputs that the response message has to contain:

• UMA success (and HTTP success): A scope request ticket

• Which has a short stated lifetime

• UMA failure (HTTP success?): malformed scope registration request

• Requester-AM token request

• Assumptions:

• Requester either already has unique client credentials at this AM, or is able to dynamically get them, or has the option at this AM of using anonymous credentials to get a token.

• The client registration process could be heavier-weight, and possibly involve other stuff that's OOB to UMA that reflects trust establishment process.

• Request message type: POST?

• Inputs that the request message has to contain:

• Client credentials (because this is "standard" OAuth using the client credentials authorization grant type ("two-legged")).

• Outputs that the response message has to contain:

• UMA success (and HTTP/OAuth success): A token for the requester to use for the particular requesting party on whose behalf it is acting.

• ISSUE (high-prio): Since we think the token has to also be bound to the particular host where this token is to be used, how should this happen? In practice, until the token has authorization scopes associated with it, it doesn't necessarily have to be "eagerly" host-bound, but is that a workable way of handling things? The AM has the right to reuse any tokens it assigns, but we don't think it's practical for the requesting party to have one big mondo token that suffices to get into all the stuff all over the Web.

• UMA failure (and HTTP/OAuth failure): bad credentials or something else went wrong.

• Requester-AM authorization request

• Requester-host request for access

• Without token

• UMA error (HTTP error 401)

• ISSUE: Does the host need to produce a particular error or sub-error if it can't even tell which of its users has "domain" over access request? At the least, it needs to distinguish for its own purposes the user in question (so that it can know which of its own access tokens to use at the AM thereafter). This is the host's responsibility, definitely not the AM's.

• With token, without sufficient authorization

• Happy path

A major theme of discussion was how to disambiguate access attempts on resources that are shared among multiple users or whose URL endpoints don't expose which user is meant. If we had "meaningful tokens", this would become easier because the requester's access token could provide that part of the story interoperably! But without that, can we continue to make the simplifying assumption that the URL either:

• Can't be common to multiple users, or

• Can have many "redirect" forms generated on the AM side that have the effect of identifying the user during the process of "advertising resources" to potential requesting parties? (See Domenico's UX examples that have "Share" buttons in the AM interface for generating shareable URLs...) 

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