Quorum was reached.
The WG call and the APAC sync are cancelled. The legal subgroup call will be run (and an agenda sent) by Adrian. Eve will "split the difference" with APAC-friendly calls and schedule one for two weeks from now vs. next week and three weeks from now.
Joni reports that we got a fair amount media attention, but no comments through the KI channel.
We got a couple of pull requests for minor typos (thanks, Sarah!) and Eve reported a few minor editorial issues and subsequently incorporated fixes for all but one. Maciej has generated drafts with all of that incorporated.
MOTION: Andi moves and Mike seconds: Approve the UMA Core V1.0.1 and OAuth RSR V1.0.1 specifications dated 5 Nov 2015, as amended with the agreed resolution to issue #229 and appropriate document metadata, for LC certification as Draft Recommendations so that All Member Ballot can begin. APPROVED by unanimous consent.
The Status section should say, instead of "...for Public Review", should say "for LC certification as a Draft Recommendation".
AI: Maciej: Edit the specs so we can turn them over to the LC to take up their e-ballot.
AI: Eve: Edit the Release Notes slightly to indicate the status change of the specs.
The discussion to gather more information is still ongoing.
We discussed the configuration data situation.
Do we want to have an official UMA configuration data property that contains an array of profiles and extensions supported (by identifying URI)? Or instead – or in addition – does it make sense to have a property for each profile and extension (as this spec proposes) where the name is the identifying URI, and then you could provides all kinds of values, or even arrays etc., for finer-grained configuration of each profile and extension? George proposes something like this:
"extensions_support is a JSON map where the key name is the extension URI and the value is a JSON object defined by the extension"
This would ideally be something baked into the UMA spec. Does it make sense to do this in "the first extension produced by the UMA WG"? Also, the line between profiles and extensions is kind of thin. The spec, in Core Sec 1.4, explicitly stays out of the business of capturing profile or extension config data (at the end of the section). Should we get into the business?
We're thinking maybe not. The mere presence of the key might normally indicate that the AS supports the extension. However, in an ecosystem where there are multiple AS's, and some do support the extension and some don't, a random RS might want all AS's to explicitly declare the situation. So that's where a key of "identifying_URI" and a value of something like a Boolean could be used. If the extension in question wants to have the AS provide a complex set of parameters whenever they do support the extension, it would be ideal to allow the parser to be able to stop the moment it knows that the AS doesn't support the extension, vs. parsing a whole object. (Think token introspection.)
For our purposes here, we can keep it simple. Let's change to a Boolean for now.
AI: George: Write up a short UIG section capturing the above discussion on profile/extension config data. (Eve will send links and instructions.)
For the question about registration failure, George recommends for the AS to return an array of resource set IDs, each with a status, with an overall error.
Are we sure we want to return a single ticket for the set of requested permissions? The RS has always had complete discretion about what to register. However, since resource sets may have scopes that are totally distinct from each other, it may be very important – party for interoperability's sake – to explicitly register requested permissions for each resource set.
Note that the RS's registration of requested permissions is just about a bundling on behalf of the client. We don't get into authorization questions until the client actually conveys the ticket back to the AS to ask for authorization data at the RPT endpoint. So we're talking syntactic errors at this point.
We're agreed that if there's an error in the request, the whole request should fail. We seem to need more discussion about multiple requested permissions vs. one returned ticket; we know there would have to be a lot more infrastructure invented if we returned multiple tickets.
AI: Eve: Rev the permission registration extension spec.
Sorry there was no time to talk about IIW impressions! Do see the notes here (more still to come). There were lots of amazing discussions about UMA, and also consent receipts, and blockchain. (And don't miss Beyonce as a Service!)
As of 13 Oct 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Mary, Robert, Maciej, Eve, Sourav, Lisa, Arlene, Mike)
Non-voting participants:
Guests: