http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13 MinutesRoll call Quorum was reached. Logistics REMINDER: The call for *NEXT WEEK *will be held *Fri Oct 21* instead of *Thu Oct 20*, just after the Legal subgroup call. IIW WEEK: Move to Friday? *NO*: We will cancel the *Thu Oct 27 call* that would have been during IIW. Approve minutes Approve minutes of UMA telecon 2016-10-06 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06 : APPROVED by acclamation. Work on UMA.next issues Sec Considerations: 7.1 and 7.3 do seem somewhat related, and could usefully be put closer together and conceptually brought closer together somehow. Also, there's a typo in 7.3: Needs to be "authentication and *user mapping* capabilities". Sec Considerations: 7.2 talks about two different OIDC topics. The first paragraph is about one topic ("RECOMMENDED for the authorization server to use OpenID Connect, and to use its mechanisms for stronger client authentication at the token endpoint, in order to strengthen the authentication of OAuth clients."). The second paragraph is about end-user identification; we should break it out. In error_details, Justin's MPD work doesn't have a redirect_user Boolean; rather it has a dynamically provided URL for where the client should redirect the RqP to. Putting this information in the response could mitigate a discovery document attack, according to some in the OIDC – this attack is the basis for the AS mixup attack. On the other hand, a client registering a callback is a case of using static-ness on the other side to mitigate attacks. Another (potential?) benefit is that the AS could bind state to the URL, making it different every time. The static declaration does make it possible to proactive send the end-user RqP to an interaction with the AS, though the spec doesn't explicitly remind people that it's possible the way it explicitly reminds people that it's possible to proactively push claims to the RPT (now token) endpoint. Options: 1. Keep static declaration of requesting party claims endpoint in config data document and don't add to AS need_info response to client (status quo) 2. Keep static declaration and ADD to AS response 3. DROP static declaration and ADD to AS response *Decide next time on which option to choose.* Regarding 3.2.4: What is the expectation about the AS providing more information about the exact resource set IDs or scopes that were at fault? Would it be a good idea to provide more guidance around error descriptions that could accompany UMA errors? Development time and deployment time are different things; would end-users see these errors? Instructions: - Address Sec 7.1 and 7.3 comments above. Will take some thought. - Address Sec 7.2 comments above. - Make an ISSUE around analyzing the spec for what its effective "operational modes" are. Look for all MAYs and natural dividing lines, and be sure to document a rationale for every MAY if possible. - Change title that has "Consent" in it to "Authorization" - Sec 3.2.4: Should be "Any one of the provided resource set identifier *s*". Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Robert 4. Eve 5. Cigdem - researcher - new to the call! 6. Sarah Non-voting participants: - Adrian - Andrew - George - James - Scott F - Jin - Justin - Ishan Regrets: - Andi - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl