https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-07-12 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-06-14 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-14: Deferred. Vermont's new law David worked on Vermont's new S.269 https://legislature.vermont.gov/assets/Documents/2018/Docs/ACTS/ACT205/ACT20... ensconcing Personal Information Protection Companies (PIPC) (see the news http://www.gravelshea.com/wp-content/uploads/2018/06/Blockchain-Terrain.pdf). The law sets up a basic framework for PIPCs, but there is a lot of room for the specifics. Tim had a role in the work as well. Sec. 5 in the law calls for a FinTech Summit to be held, and the Department of Financial Regulation to take further steps. There could be appetite for learning how UMA can provide value in separating "personal information" services from "protection" services. Thomas served as a moderator at the DC blockchain caucus. The blockchain startup CEOs mentioned Vermont as leading in the area of "blockchain sandboxes", but being blocked at the federal level. Propy is a new company in Vermont doing https://blog.propy.com/propy-announces-first-us-pilot-with-vermont-23ec0b2d3... land registry/real estate recording. Because of the US blockages, the first POC was in Ukraine. What about UMA with and/or vs. DIDs? Eve's recent answer when asked: "I know of a couple of projects that combine them, and I consider them complementary. UMA has long had a design principle about being “ID-agnostic” (see the Charter https://kantarainitiative.org/confluence/display/uma/Charter) and it seems to work. Also, the actual consent, permissioning, and access control mechanisms built into SSI-type systems, as far as I can see, aren’t directly related to their blockchain tech but are part of the rest of their app stack. So they [the consent/permissioning/access control mechanism] could be proprietary, OAuth/UMA-based, etc." More specifically, UMA has several places where identifier/claim sources come into play: How a RO identifies themselves to the RS, how a RO identifies themselves to the AS, how the AS gathers claims from the RqP interactively, and how the client conveys a claim token to the AS token endpoint. Mike notes that a DID is a reference to what UMA calls a claim token and, we think, doesn't specify a format. The BSC DG report https://kantarainitiative.org/file-downloads/report-from-the-blockchain-and-... has a figure illustrating the role of blockchain tech (potentially necessary, but always insufficient) in an app stack. Leadership team elections The current leadership team roster is here https://kantarainitiative.org/confluence/display/uma/Leadership+Team. *MOTION:* Sal moves: Eve to serve as chair for another annual term and Maciej to serve as vice-chair for another annual term. APPROVED by unanimous consent. New issue 361 Next time we open up the specs, we'll take a look at this. Discuss/compare financial and health "multi-portal problem" use cases - Discuss/compare HEART http://openid.net/wg/heart/ use case Alice Shares Clinical Records With Her Spouse http://openid.net/wordpress-content/uploads/2018/07/AliceSharesClinicalRecor... and Origo use case (see their architecture https://www.origo.com/news/PensionsDashboardArchitecture.aspx description, adoption https://www.origo.com/news/Bringing_Pension_Industry_On_Board_Pensions_Dashb... recommendations, and performance testing https://www.origo.com/news/Pensions_Dashboard_Scalability_Release.aspx news) for cross-sector implications of the "multi-portal problem" - May relate to issues 53 https://github.com/KantaraInitiative/wg-uma/issues/53 (Assess interest in making AM a formal client of APIs for policy servers, interaction services, etc.) and 106 https://github.com/KantaraInitiative/wg-uma/issues/106 (Have an API to let an RS register the user’s sharing preferences/policies directly) Maybe new UMA infrastructure (Eve had been imagining that you need a formal policy API and a "consent API access token" or CAT!) isn't strictly necessary, at least for now. Looking at the Origo solution (see the two-part UK Pensions Dashboard scenario in the "Legal role definitions https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7..." slides), its Pensions Dashboard service is the unique client app that then presents a policy-setting service to the RO. It needs the two-step approach that Origo uses, but it works for then sharing with RqPs who aren't equal to Alice, and for centralized policy setting with a client where the business climate (as in US healthcare today) wouldn't be friendly to each AS not working with competitor RS's running policy interfaces. This solution may be a common design pattern. AI: Eve: Intro Nancy and David in email to pursue the topic further prior to the next call (which is *July 26*). Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Sal 2. Maciej 3. Eve 4. Mike Non-voting participants: - Thomas - Nancy - Bjorn - David Thelander - lawyer - licensed in Vermont, SEC background, Gravel & Shea, blockchain and identity trust companies Regrets: - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl