http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 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: Deferred. UMA V2.0 work *#293 https://github.com/KantaraInitiative/wg-uma/issues/293*: Consensus on pushing only a single claim token being "hunky dory" (a good idea). *#298 https://github.com/KantaraInitiative/wg-uma/issues/298*: The redirect-back paths look much cleaner now. *#290 https://github.com/KantaraInitiative/wg-uma/issues/290* (Generality of RReg spec?) and *#296 https://github.com/KantaraInitiative/wg-uma/issues/296* (Out-of-the-box profiling for tight AS-RS coupling): We looked at the new oauth-uma-ticket rev 00 https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-00.html experimental spec. General support for this approach, though we don't have a federated authorization spec yet. Can we sync the high-level flow diagram more with OAuth's abstract protocol flow diagram? Andi says: "I like this effort to re-architect the way the specs are laid out, Eve. Happy to help if I can (dm me later if so and we can discuss)." Cigdem says: "I think if we want to provide a comparison to OAuth - comparison via "abstract protocol flows" maybe more appropriate. In this case (C) Authorization grant: includes ticket, claims collection, RqP interaction etc. for UMA, After that we can have the more detailed flow diagram." So we could have two diagrams, where the first indicates explicitly the mapping to OAuth's letters A through F. Why do we still have registration_endpoint metadata? Sort of historical (because our group wrote the first dynamic client registration spec)? Should we consider dropping it? People could just use the OIDC spec, or the draft OAuth metadata spec, to declare their registration endpoint. Eve will make an issue to consider this. (DONE https://github.com/KantaraInitiative/wg-uma/issues/305.) Ishan points to the OIDC wording: "Additional Client Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session]" Since we've never had an "UMA grant" per se before, should we overtly label this as UMA2? Seems to make sense since UMA1 is out there (and we have semantic versioning!). Eve has done so, sort of, but will make it more obvious. "Permission" has been defined, but is there actually any reason to do so? It doesn't seem like it. In the spec swimlane, the redirect and redirect-back, there should probably be two arrows/steps, since there are two whole sections for this. This is only a "sample high-level flow" in that there are pushed claims followed by interactive claims gathering followed by success. The client approaching the resource first, with the whole ticket flow etc., is not optional. The swimlane should use very short phrases with a list following, a la 6749's style. Sec 1.3.2's claims collection discussion should clarify that while claims collection is probably not really optional, claims don't strictly have to be collected through UMA messaging; it could be done out of band (don't use that phrase?). In the section on Endpoints, the last paragraph may be out of place. *AI:* Eve: Propose an ad hoc early next week for at least her, Andi, and Cigdem (others welcome) to work on the refactored specs. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Eve Non-voting participants: - Ishan - John - Crina Regrets: - Justin - Maciej - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl