UMA telecon 2014-12-18

Owned by Eve Maler
Last updated: Dec 18, 2014

UMA telecon 2014-12-18

Date and Time

Agenda

  • Roll call
  • Minutes approval if quorum
    • Sample motion: Approve the minutes of UMA telecon 2014-12-11 and read into today's minutes the notes of ad hoc WG meetings held since 2014-12-04.
  • Interop testing status and meeting schedule review
    • See below
  • Review of latest Core and RSR drafts (to be published today, along with a fresh list of outstanding issues and their status)
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

MOTION: Andi moves: Approve the minutes of UMA telecon 2014-12-11 and read into today's minutes the notes of ad hoc WG meetings held since 2014-12-04. APPROVED by unanimous consent.

Interop testing status and meeting schedule review

We have the ability to use a session next Monday to continue our "feature work", but not willingness. Let's see at the end of this call where we are.

We ultimately agreed to use next Monday solely as a working session to bash out the callback URI and requesting party claims endpoint spec text. A sub-team will also work on the security considerations over the next short period of time. Otherwise, the spec editors will incorporate and publish the decisions made today shortly.

Issues

The current list of issues is as follows.

Substantive discussions:

  • *Callback URI/requesting party claims endpoint (Maciej)
  • *Token introspection questions (115) (Eve)
  • *Scope string proposal (Eve)
  • *Scope level/permission level in RPT proposal (Eve)
  • *Config data inconsistencies and issues (90) (Mark/Eve)
  • *Soften HTTP error response (112) (need to discuss at least a little)
  • *Security considerations (10) (need to figure out how to cover this prior to Jan 5 vote)
  • *ETag vs. _rev (Zhanna) (Eve sent a query out to Paul Bryan on this!)
  • *Shorten prot and authz scopes to strings (many)
  • *Simplifying the configuration data (Eve)
  • *Nonunderstood parameter proposal (117) (Zhanna, if proposal sent before meeting - UPDATE: Zhanna okay with deferring per GitHub comment)

Spec text reviews:

  • *Claim token profiling considerations and base64 encoding
  • *RSR resource_uri (110) (name change to "uri" ok?)
  • *Endpoint names (84) (straightforward)
  • *Mention OIDC dyn client reg (116) (straightforward)
  • *Soften Binding Obs mention (110) (straightforward)
  • Register .well-known/uma-configuration (45) (straightforward)

Okay to close without action?

  • WWW-Authenticate (76)
  • PbD-PIA mention (68)

Okay to backlog the rest?

Other AIs owed?

Soften HTTP error response (112) (need to discuss at least a little)

The question is whether we remain "pure REST" or acknowledge that the world is impure around often returning success while also enabling authentication/authorization to get "the same resource" that actually delivers different content. Is it just a matter of softening our MUST about returning a 403 in the case of a client with no RPT to a SHOULD? If an RS returned success and a representation of the resource, then what about registering the permission and returning the ticket?

The philosophical question of RESTfulness here is that if it's an "UMA-protected resource", it can't simultaneously be public. But everyone does it!

The consequences here are about interop if we soften, and getting UMA taken seriously and seeing massive UMA non-compliance to this spec assertion if we don't soften. The interop consequence is perhaps mostly due to the fact that we don't have time right now to figure out the right design when it's not a 403. We could learn that over time, by observing implementer practice. E.g., maybe the ticket is returned in the header. And that brings up: Why not always put the ticket in the header, even for a 403?

Robert recommends briefing people about what we currently know, since we obviously don't know everything now! This is a good entry for our implementer's guide that we want to write. We could ask Justin to write up what he suggests. Eve proposes: Say SHOULD for 403 instead of MUST; say that non-403 behavior is unspecified; recommend consulting the UMA Implementer's Guide (a new doc that we have to create and populate!) for advice. It's a kind of "readme". Robert adds: Mention the new Implementer's Guide in the Compatibility Notes section!

We have consensus.

Token introspection questions (115) (Eve)

Eve proposed adding nbf from JWT, and syncing to the JWT names for exp and iat. Mark supports all of this, and suggests making exp optional to support a lack of expiration of a permission. We have consensus on this. Robert suggests spelling out the property names for convenience.

The registration of the "permissions" JWT claim looks okay. Maybe say "time-limitable" instead of "time-limited".

What should we say about Eve's proposal #2 around mixing "scope" and "permissions"? It's maybe interesting, but confusing. If we don't do that at all, perhaps disallow the "scope" property at the top level entirely. It's always possible for someone to write their own RPT profile that allows it and gives meaning to it in the V1.x timeframe. Alternatively, it could be present but we say it has no meaning in this profile context; it MUST be ignored. George's take: Since it's an optional property in the response, why say to ignore it? Just say to leave it out. Eve likes this, but also likes the idea of leaving the other properties that don't clash with permissions-level stuff to exist for experimentation. Proposal: MUST leave off top-level "scope"; say nothing else. We have consensus.

Scope string proposal (Eve)

Agreed by acclamation!

Relatedly, can we now finally shorten our OAuth scopes for protection and authorization? And if so, what should the keywords be? Is there a potential for scope string clashes? The winners are: uma_protection uma_authorization. Let it be so!

Callback URI/requesting party claims endpoint (Maciej)

We looked at Maciej's email writeup. George recommends that the state parameter be required. Also we should strongly RECOMMEND that the client pre-register the callback URI, and give examples about how to do this using the dynamic client registration spec(s).

Config data inconsistencies and issues (90) (Mark/Eve)

Regarding getting rid of four config data properties: Eve thought this was overreach, but Mark makes the case that since an UMA client may be truly new to an AS (and RS) at the time it approaches the resource, it may really need this information.

Proposal: Let's switch to full URIs for the API extensibility profiles and RPT profiles supported in the configuration data, and stick to the "bearer" keyword only for the OAuth bearer token. Let's further always require the presence of the profile URIs/keywords supported, rather than defaulting them; if they're MTI, they still have to be present in the config data. We have consensus.

ETag vs. _rev (Zhanna) (Eve sent a query out to Paul Bryan on this!)

Paul Bryan had originally proposed _rev and _id because CouchDB has them. So it's not perfectly RESTful, but it's commonly used in NoSQL. If we take it out, people might add it back in! Maciej is okay leaving it in; Zhanna would like to take it out so that the protocol is "clean" in this respect. Would we take out both _id and _rev in that case? We could then extract this text from the spec and move some of it to the new UMA Implementer's Guide as non-normative advice. Actually, _id isn't duplicated in the response; only _rev is. And it is pretty darned handy to have _rev in there too, so that the body-processing software still has the rev available once the header-processing software is done. Do we even want to rip out the ETag mechanism? This is too disruptive.

Proposal: Rip out only _rev; put something in the UIG about how it's possible to add _rev to assist body-processing software. We have consensus!

Nonunderstood parameter proposal (117) (Zhanna, if proposal sent before meeting - UPDATE: Zhanna okay with deferring per GitHub comment)

Let's capture this in the UIG.

Security considerations (10) (need to figure out how to cover this prior to Jan 5 vote)

Maciej, Mark, potentially Thomas, hopefully Domenico, and Eve are interested to work on this section over the holidays. The presumption is that this text is not "new feature text" and can be done shortly before our Jan 5 call for consideration.

Claim token profiling considerations and base64 encoding

Let's copy JWT and OIDC and say base64 URL encoding. It's generally popular and URL-friendly. It loses the "=" at the end.

RSR resource_uri (110) (name change to "uri" ok?)

Fix the "IThe" typo in the definition of the property. Is the "uri" property name okay? George thinks of a "thing" when he hears "URI"; a leaf node of a path. But it could be a folder for a photo album, or something totally unretrievable – a whole directory, say, that would give an error page. There is definitely a bit of philosophical hand-waving around abstract resource sets and true web resources. Maybe we should point to the UIG as one example of a place where there are implications of resource discovery discussed around this property.

Do we want this to be an array? Right now the resource set has a single type, a single icon_uri, etc. If we want to think about broadening this, it may have to be a V1.x timeframe thing. Our abstract notion of resource "sets" is somewhat theoretical at the moment. We think this is only the initial step in the discovery mechanism, and not the final step. George wonders if we should leave it out for now. Maciej points out that it's optional; is that okay? George suspects that we'll eventually need to have a discovery URI array vs. the simple "uri" property we've got now, including visual hints and so on. This is discussable in a UIG at length. This also militates for keeping this firmly OPTIONAL for now.

Soften Binding Obs mention (110) (straightforward)

The new wording looks okay.

Attendees

As of 4 Dec 2014, quorum is 6 of 11. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Yuriy)

  1. Eve (can attend next Monday)
  2. Thomas (can attend next Monday)
  3. Mark (can't attend next Monday)
  4. Andi (may be able to attend next Monday - 75% chance)
  5. Mike (can attend next Monday)
  6. Sal (can attend next Monday)
  7. Robert (may be able to attend next Monday)
  8. Domenico (can attend next Monday)
  9. Maciej (can attend next Monday)

Non-voting participants:

  • Marcelo (can attend next Monday)
  • Zhanna (can attend next Monday)
  • George (may be able to attend next Monday)

Next Meetings

  • Monday, Dec 22: ad hoc 1.5hr telecon - this is for the sub-team working on the spec wording for the callback URI and requesting party claims endpoint
  • No meeting Thu Dec 25 because of Christmas holiday
  • Monday, Dec 29: ad hoc 1.5hr telecon? (reserve for interop/security considerations/editing team)
  • No meeting Thu Jan 1 because of New Year's Day holiday
  • Monday, Jan 5: special quorate 1.5hr telecon
  • Thursday, Jan 8: regular 1hr telecon (no ad hoc pre-meeting)

Â