UMA F2F 2011-10-20

Date and Time

• WG F2F on Thursday, 20 Oct 2011, at 1-5pm PT (time chart)
  • Skype line "C": +9900827042954214
  • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214

Agenda

• Roll call
• Approve minutes of 2011-10-06 meeting
• Action item review
• Discuss Trust Model and new constellations
• Discuss and resolve UMA core spec issues
• Discuss latest OpenID Connect and OAuth integration needs
• AOB

Attendees

As of 20 Oct 2011 (pre-mtg), quorum is 7 of 13.

(Paul became a voting participant again before the start of the call. Sampo is looking into switching to voting participation.)

1. Mohammad, Alam
2. Bryan, Paul
3. D'Agostino, Salvatore
4. Maler, Eve

Non-voting participants:

• Sampo Kellomäki
• Henrik Biering

Sampo's company Synergetics implements a number of protocols, including UMA.

A number of observers also joined us to see what UMA is about.

Minutes

New AI summary

Roll call

Quorum was not reached.

Approve minutes of 2011-10-06 meeting

Deferred due to lack of quorum.

Discuss and resolve UMA core spec issues

The new Section 1 conceptual stuff was agreed to be generally helpful in reading the spec this week.

We agree that UMA is basically an "advanced application" of OAuth rather than a mere extension.

The approach taken with OAuth2 on extensions was an established IANA registry for "short names", or a fully qualified URI for anything that isn't registered. This applies to grant types, token types, and possibly other things (return codes?).

Let's use "types" instead of "formats", to convey the semantics and protocol implications of the conformance options around tokens and claims. For extensions, we could reuse OAuth-style wording: "new XXXs can be created by assigning them a unique absolute URI, such as a fully qualified URL" (and supply a cross-reference to the relevant spec to explain the jargon). OAuth draft 22 Section 8.1 has an example of the whole URI/registry approach; we should try to copy at least the URI portion as much as possible. We have no appetite for inventing another stupid registry. So let's stick with the URI approach.

While we're still using the XRD (not a JSON-based) format for metadata, should we name these token_type and claim_type (singular), since the XML element gets repeated? Or should we use a space-separated list as the value of a single element (or JSON structure eventually)? Open for now; don't optimize prematurely.

In the Section 2 intro, reverse the order of the lists. First explain what Phase 1 entails, and then explain that if these actions are taken, these are the results.

In Section 2.2, it was noted that the hData use case likely won't be fully dynamic with respect to client credentials. Likely each DAS will be owned by one insurance company.

In Section 2.2, we are reconsidering whether we need to make the host ID a component of the resource set registration API path. The host access token would disambiguate which host is approaching, but then it sort of goes against HATEOS (hypertext as the engine of application state, one of the "pillars of REST"). Let's provisionally remove the requirement for host client ID uniqueness and host ID appearances in the resource set registration API.

In Section 2.3, for one thing, we need to check whether the external doc references need to be updated. Also, we think the authz code flow MUST be made MTI. Other flows MAY be used, and we can even mention that the SAML bearer assertion is a flow that SHOULD be supported in SAML-friendly environments. We need to add a conformance option in the AM metadata for this. Call it "host_authz_grant_types" and point to OAuth2 Section 1.3.

Take out the parentheses around the last sentence of the middle paragraph in Section 2.3.

In Section 2.4.1, let's fix the first sentence. "A scope is a bounded extent of access that is possible to perform on a resource set. A host MUST refer to a resource set's available scopes using URI references. The scopes available for use at any one host MUST have unique URI references so that the host's scope descriptions are uniquely distinguishable. The URI reference MAY include a fragment identifier. Scope descriptions MAY reside anywhere. The host is not required to self-host scope descriptions and may wish to point to standardized scope descriptions residing elsewhere." Then we can continue with the example.

Paul has added a nuance in today's draft that lets us do away with putting _id in scope and resource set descriptions. The AM MUST return an _id whenever the host asks to see a copy of what's been registered, but the host no longer supplies that field. Scope descriptions don't even need _id because the AM just looks those up and never returns them to the host.

In Section 2.4.2, take out "has the name "resource_set"". Check globally for other instances.

We use tokens to encapsulate multiple scopes (permissions) in a somewhat different way than OAuth does. They have simple strings, and we have big permission structures.

At the end of Section 2.4.2: Do we need a way for the host to indicate to the AM that the latter needs to update its understanding of scope descriptions? Do we need the equivalent of "ETags for scopes"? Let's open an issue, and assign it to Paul.

In Section 2.4.3, maybe someday we can shorten this considerably by pointing to an IETF spec Paul intends to propose that codifies the basic CRUD operations people want to do in a REST API. Then we could specify the "Level of CRUDness" we conform to.

We should remove the /host/{hostid} bits of this section. Paul promises to write his LoCRUD spec very shortly, and it will specify that the AM would add an _id property when asked. This is the way CouchDB behaves, and it's considered good practice by some.

In Sections 2.4.3.x, the concrete examples should be removed. We should extend the worked example that's now in Section 10, to add full requests and responses so that the whole thing tells a story. It's okay for this section to be really long. Include error responses.

In Section 2.4.3.5, we acknowledge that it's not very HATEOS (RESTful) to provide the raw resource set IDs in the response array, vs. URLs. Tough.

Regarding Section 3.1.1, we have a big constraint around requiring the host to determine, at the time a resource is being accessed, which authorizing user wanted that resource to be protected. By the way, we share this problem with OpenID Connect clients that approach an OP without an access token yet, looking for a particular claim about a particular user. Paul argues that "ambiguous-user" is not an UMA-level error. It's the host's problem even before it knows whether it should be UMA-protecting the resource! "Confused host" is not our problem. This should be removed. It impacts the intro to Section 3.1 as well.

In Section 3.1.2, Paul has changed the response to 401 from 403; it was odd to have a WWW-Authentication in a 403. According to the OAuth bearer token spec, the no-token circumstance is undefined because the resource server could choose to return public information outside the context of any particular access token. 403 implies stopping and not retrying. We're treating it as signaling that you have to get challenged over at the AM.

We're happy with Section 3.1.3.

In Section 3.1.4, we like the idea of putting the ticket in the body rather than a header, similar to what was done in Section 3.4.1 of our spec (and Section 3 of the OAuth bearer token spec). E.g.:

{
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de"
}

Section 3.6 should say "AM-Requesting Party", not "AM-Requester".

We need to ensure that the host is instructed that it MUST NOT give access where its token status check did not reveal a currently active permission for that type of access. Don't mention in the spec anything about the legal system that could compel a host to give access, e.g., to the police, based on needs other than the authorizing user's needs. ("GET /STAPO" --> 400 Bad Request)

In Section 3.4, it turns out we don't need to have the host pass along the requester's access token to the AM, because whatever requester actually shows up with the ticket it's given, the requesting party operating it will have to provide whatever claims are necessary. So even if a rogue requester gave someone else the ticket, it wouldn't cause authorization to be given out of turn.

In Section 3.4.1, we have to ensure the ticket is randomly generated to avoid a DoS scenario. See Paul's email.

Discuss Trust Model and new constellations

What are the gaps? To make our model useful to people who have to generate operational guidelines or deployment profiles, we need to present it as a set of risk management decisions. We probably need a best practices document. Use cases we need to assess would include the "George Clooney flag" for auditing inappropriate access, rogue operators of services, the need to revoke all access for someone who's stalking you or you divorced, mandatory access controls that override your constraints by subpoena, etc. The healthcare environment provides many useful examples. "The protocol is agnostic to your legal issues." The technical layer has to express what's legally possible, and sometimes it doesn't!

We should add this to future meetings to get a plan in place.

Next Meetings

• WG telecon on Thursday, 27 Oct 2011, at 9am PT (time chart)
• WG telecon on Thursday, 3 Nov 2011, at 9am PT (time chart) – NOTE: UK and Europe have changed their clocks so this will appear one hour earlier than usual to participants in those locations
• WG telecon on Thursday, 10 Nov 2011, at 9am PT (time chart) – NOTE: back in sync on most apparent time differences around the world – ALSO NOTE: – Eve regrets; who will serve as chair pro tem?
• WG telecon on Thursday, 17 Nov 2011, at 9am PT (time chart) – NOTE: Likely Eve regrets; who will serve as chair pro tem?
• NO WG telecon on Thursday, 24 Nov 2011 – U.S. Thanksgiving holiday
• WG telecon on Thursday, 1 Dec 2011, at 9am PT (time chart)