http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-31 MinutesRoll call Quorum was reached. AI: Eve: Check the rolls and reach out to Ran at a minimum. Approve minutes tbs Publication of new spec The extension spec is here <https://docs.kantarainitiative.org/uma/draft-uma-claims-sec-ext-v1_0.html> (versioned) and here <https://docs.kantarainitiative.org/uma/draft-uma-claims-sec-ext.html> (symbolic link to "latest draft"). Wide ecosystem analyses and solution proposals Let's try and analyze the problem space thoroughly enough to collect solutions and match them all up. Eve presented a new document, UMA wide ecosystem challenge analysis <https://docs.google.com/document/d/1lJXDFzlq8j-m0f8mELjqYcX6PPcYSjOuxiGHzwU7dDE/edit?usp=sharing>, that walks through thoughts on how trust elevation will likely be done in narrow, medium, and wide ecosystems and what the practical challenges are with the latter. We looked at Domenico's excellent diagram (produced in 2011!). We worked on "trusted claims" a lot in the past; it falls in an area that could be broader than UMA's scope, meaning that others might find it interesting to work on and use as well, so we had put it aside. The diagram shows, roughly, a kind of "UMA-protected requesting party claims" picture. Mike observes that having the "OpenID Connect AS" entity request a token from the "resource owner's AS" might be another solution. Adrian asks: Is a certificate helpful for solving this problem? A policy condition could require Bob to authenticate strongly in a certificate-based way. We're not sure this particular type of policy is relevant to the wide ecosystem question. Mike notes: "Not to be overly negative... but the wide ecosystem use case is really a long shot for adoption. Its really hard to get network economies of scale." Adrian has previously talked about how an AS could usefully accept federated logins by its ROs from an RS. The medium ecosystem diagram shows a similar example, only on the client side – the AS accepts federated logins from the identity ecosystem of the service that the client participates in. Justin describes FHIR as a common/universal API that should be heading to universal acceptability, and thus ultimately totally open acceptability for, say, every conforming client. The current world is more like static onboarding, a la Microsoft HealthVault <https://account.healthvault.com/us/en-US/Directory> with its ~400 clients. Adrian says the Mass. Medical Society is looking at such a thing, but there's no evidence of any move to support the wide ecosystem approach yet, despite a strong wish by some for this type of disintermediation. The example of a Volvo app that unlocks the engine shows that you may also want to grant access to a friend or family member. This is a valet key for real. [image: (smile)] Attendees As of 20 Feb 2016, quorum is 7 of 12. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah, Ran) 1. Domenico 2. Kathleen 3. Andi 4. Maciej 5. Eve 6. Mike 7. Sarah Non-voting participants: - Mary - Jin - Mark - Adrian - James - Scott - Justin Regrets: - Sal - Robert *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl