Re: [WG-UMA] Draft minutes of UMA telecon 2015-08-27

Maciej has implemented nearly all of the changes we discussed on today’s call, and should finish up tomorrow. I’ve closed the corresponding issues. By the weekend, we’ll prepare rendered spec versions for everyone to review. Everyone please take a look at the issues (there’s only a few remaining V1.0.1-related open ones — check the closed ones with the V1.0.1 label https://github.com/KantaraInitiative/wg-uma/issues?q=is:issue+is:closed+labe... instead) to pick out the issues you care about. (That should at least include issues you submitted or commented on...) If you want, you can review deltas in context anytime by clicking on the gray-text coded links to the right of the “commit” lines, e.g. “dba185f” at the bottom right in the screenshot example below. But also, when you finally have the formatted specs in front of you, please take responsibility for looking closely at those issues, at a minimum, and ideally also reading through the specs for whatever else you might find. More eyeballs are better, and reporting earlier is better than reporting later. We’ll seek quorum on Sep 3 (a regular one-hour call) to: Discuss anything substantive/normative that remains Edit the specs in real time as required Consider a motion something like the following: “Approve UMA Core rev (whatever) and OAuth RSR rev (whatever) to proceed to Public Review prior to consideration as Draft Recommendations [and contribute them as IETF I-Ds?].” (I thought we needed LC approval for this stage, but in looking it up, I think we only need it after the Public Review and on the way to Member Ballot. I’ve reworked the timeline here https://docs.google.com/document/d/1c50top8X6Aqw3CEVeX_SD2THqO508ihs14QwLem0....) Thanks, everyone! Eve

On 27 Aug 2015, at 10:33 AM, Eve Maler wrote:

Many thanks to all the UMAnitarians who made it onto the call today — we made great progress. I really apologize for having the call run over so long. And apologies also to Jon Neiditz, who’s been attending the legal subgroup calls but for whom this was the first WG call — normally I would have had him say a few words of self-introduction… We’ll do that next time, I promise!

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-27 Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the minutes of UMA telecon 2015-08-13 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13 and UMA telecon 2015-08-20 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20. APPROVED by unanimous consent. Conclude on topic: Restricting GitHub editing Deferred. Workshop space No takers at the moment. Formatting the specs Maciej has an XSLT for turning UMA's XML2RFC source into Kantara specs. He is willing to take it the rest of the way. Let's pursue this. Issue resolution work #163/#168: Given the early stage of UMA implementations, and given the technical soundness of the fig-leaf logic for MAY/SHOULD/MUST, we are going to add the ticket parameter in the header, and greatly soften the need for the ticket body. #176: Why would an RS want to indicate to a client that it's giving it a public version of the resource, but that there is a protected version, and it can't help the client seek access to it right now? Then the client could a) know that there's more, and b) choose to try later. Should the RS try again on its own later? No, because it has no relationship with the client; why would the RS take action on its behalf? The RS could, of course, respond with a non-UMA response (which gives no hint of anything wrong). So if there's any option at all to respond with "an UMA response", then there should be some reason to use it. Suggested: A new header. James suggests (from the HTTP spec https://tools.ietf.org/html/rfc7234#section-5.5): Warning: 199 UMA Authorization Server Unreachable The client is not allowed to take any automated action beyond displaying this text to the RqP, but that lets the RqP know that there's "more" behind the RS. "If the RS received an XXX error from the AS, and did not receive a permission ticket, then is unable to create a WWW-Authenticate: UMA header and MUST include a header of the following form: "Warning: 199 UMA Authorization Server Unreachable"." #172: Justin is looking for more implementation guidance, which we're thinking should really go in the UIG rather than here. Should we include a cross-reference out? Let's do it. We will stick to language that supports the RFC 2119 normative assertions in the spec. #171: Eve SWAG'd some text guessing that we would require at least one scope to be registered in future. But no one?? is crazy about making this kind of a decision now. So let's revert it. #164: Goes away because there are no mandated HTTP codes anymore! #161: We are cycling on Justin's wording: Note: When a client attempts access to a presumptively protected resource without an RPT, the resource server needs to derive the authorization server and resource set identifier associated with that resource from some other aspect of the client's request. This effectively means that the resource server’s API needs to be structured in such a way that the client's RPT-free request uniquely identifies the resource set. In practice, this information likely needs to be passed through the URI, headers, or body of the request. Done. #160: Looks good; we'll get review of the whole spec later. The last STRONGLY RECOMMENDED should be in active voice, not passive. #151: We shouldn't have the AS check for URI host/scheme matching, so the second part of the third paragraph in RSR Sec 4 should come out. We don't want to add any SHOULDs. #144: Just needs s/s/z/ in AS. Shall we close all of the issues at this point? We're ready to close them and review the final text, once Maciej has done the final edits tonight. We may be ready to vote on progressing the candidate Draft Recommendations to the LC next Thursday. AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. AI: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Maciej: Write as many sections for the UIG as he can. AI: Justin: Write a UIG section on default-deny and race conditions. Attendees As of 21 Aug 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike, Jon) Eve Thomas Mike Maciej Arlene François Jon Sal Non-voting participants: Sarah Ishan Mark James Justin Dazza Andi

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com