Quorum was reached.
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.
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.
The current list of issues is as follows.
Substantive discussions:
Spec text reviews:
Okay to close without action?
Okay to backlog the rest?
Other AIs owed?
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.
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.
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!
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).
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.
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!
Let's capture this in the UIG.
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.
Let's copy JWT and OIDC and say base64 URL encoding. It's generally popular and URL-friendly. It loses the "=" at the end.
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.
The new wording looks okay.
As of 4 Dec 2014, quorum is 6 of 11. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Yuriy)
Non-voting participants: