http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13> Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the minutes of UMA telecon 2015-08-06 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06>. APPROVED. Trust Elevation TC request Mike will follow up on Andrew H's request to write something up on UMA for the TC document. He's already on that TC. GitHub repo status Eve's xmlgrrl repo for UMA-Specifications is now moved over to the KI side <https://github.com/KantaraInitiative>. Issue resolution work We agree that a patch release is still the right thing to do. We assigned milestones afresh to all of the current issues. Eve will duplicate issues where they ultimately apply to subsequent releases. Issue 161/162 discussion: The constraint is that the RS must be able, based on the C's access attempt with no token and no other context, to distinguish the AS and RO that match the protected resource set. In practice, this likely means that the URI needs to be unique per resource set. Let's mention this constraint in a few places. E.g., in Core Sec 1.3.1 and Core Sec 2. And we also have to put it into RSR Sec 2 and Sec 2.2. Issue 163 discussion: 200 with a special header has been discussed. Let's align the header with the future! What do we think the V1.1/V2.0 header would be for the ticket, the RO-specific information the client would need, etc.? WWW-Authenticate: UMA parameters. So the name of this parameter would be what? We want to convey that we're not giving an error code, but we're starting a process that requires some additional action if they want to get the protected representation (ish) of the resource. We already have as_uri=as_uri and Justin would suggest that we have ticket=ticket in future. The sheer presence of the UMA header is all that is required – nothing else. Issue 172 discussion: The feedback from the implementation process is that what's in the spec is not enough. The OAuth spec has more guidance on this type of thing. Can we be more specific without saying exactly what the lifecycle is? Can it be forever or not, e.g.? The spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxEy2GnOLv4/edit?usp=sharing> has a few more notes and champion assignments. 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 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike) Eve Irwin (regrets for next three telecons) Arlene Thomas Mike Maciej Domenico Sal Non-voting participants: Adrian Justin Sarah Nat Mark Jin Scott Regrets: Andi Robert François Ishan James Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com