http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09 and UMA telecon 2017-04-20 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 : APPROVED by unanimous consent. Logistics Who is traveling next week, particularly next Thursday, and can't make a WG call? Justin and Mike. Mike's got Yuriy reviewing the specs and starting UMA2 implementation right now. Eve's team is also starting implementation. There is also the IIW "coming-out party" sort of opportunity for the refactored specs, to get feedback. Assuming we gain directional consensus on the refactoring today, let's schedule a special WG meeting for Friday May 12 at 9am PT/11am CT/5pm UK for the purpose of approving Draft Recommendations for a Public Comment period. The idea would be to gather feedback between now and then, particularly implementation feedback, and put it into editors' drafts timely. UMA V2.0 work Wrt the refactoring proposition, there are two big questions: - Do the specs taken together have within them everything that was important in Core and RReg (no important testable assertions missing)? - Is the handoff between the specs correct and does it not drop anything on the floor? Eve explained how the concept of permissions is handled in the Grant spec; this will be a key point for implementers and readers to test. In fact, issue #306 https://github.com/KantaraInitiative/wg-uma/issues/306 is directly related to questions about permissions and resource-specific scopes, so please keep this in mind. For #307 https://github.com/KantaraInitiative/wg-uma/issues/307*,* you'd need a standards-track IETF spec to do a real IANA registry. Maybe we should at least take a registry template-like approach. The FedAuthz spec only extends Grant; it is not generally applicable to all OAuth grants. (Maybe seeing it will inspire someone(s) to work on a more generic federated authorization approach together...) So this is a backing-off of the question in #290 https://github.com/KantaraInitiative/wg-uma/issues/290! What is the correct description of these specs? What is "feature" and what is "benefit"? Justin called it "uma-ticket" because the permission ticket pattern is the essential feature of the grant. "User-managed access" has been the defining phrase for the set of benefits we targeted with our design principles. The file name/spec identifier should definitely have the word "grant" in it. So replace "ticket" with "grant"? That seems to be the thing to do. The "Adrian clause", about the RS getting to apply its own authorization controls, now sits in FedAuthz. Why? It only makes sense when you enter the land of federated authorization, when the RS and AS are actually operated by different parties. Consensus on continuing with the refactoring approach. *AI*: Eve: Cancel next week's meeting and move the meeting of two weeks from now. (DONE) *AI:* Eve: Reach out to George about his UMA 101 session. (DONE) *AI:* Eve: Edit specs so that it's oauth-uma-grant and an xref of "UMAGrant". (DONE - Grant rev 02 https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-02.html and FedAuthz rev 02 https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-02.h... ) *AI:* All: Review and implement specs, and submit issues ASAP so we'll be in a position to get the Public Comment period under way in mid-May. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Andi 3. Eve 4. Mike 5. Cigdem Non-voting participants: - Justin Regrets: - John - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl