https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-23 Roll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-08-09 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-09: APPROVED. Discussion about RS-based authorization flows - See thread (1 https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-HerdEt-7v... , 2 https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-2o4_QY-Hg... ) There would be concern if the additional flow makes UMA2 work in a different way. In other words (as said in the chat), "we want stable UMA". Is this trying to create multiple AS's in some fashion? Actually, it's taking advantage of the conceptual availability of the RS as "its own AS", in a way, by virtue of the Adrian clause: "However, the resource server MAY apply additional authorization controls beyond those imposed by the authorization server." But maybe it's more like a PIP (policy information point) vs. *imposing* authorization controls per se, because it's passing along claims with the permission request that it gathered from the requesting party at tokenless resource request time. This suffices for a case where, as Pedro describes it, the "RS is the RO" – it's a single enterprise that runs both the AS and the RS. As an aside, UMA's lack of perfect symmetry in various ways make it somewhat more difficult to solve the corner cases we're starting to see now. - RO vs. RqP, with nothing said about the RO's AS user agent and means of proving themselves to it through authentication/claims collection: Our previous analysis showed that "decoupled" use cases (bank teller Bob needs to share with someone who is a "true" Alice) would find it useful to test Alice rigorously, in an OOB band fashion, to prove who she is. We thought of this as "backwards UMA". - AS has a means of claims collection but the RS has no means to leverage the claims collection itself: This is where Pedro's extension is starting to fill in a gap. It would be interesting if the same claims collection infrastructure is getting reused. The whole claims collection infrastructure and abstract flow, as noted in a previous meeting, looks like it could be a sort of model for a wide variety of grants. Next steps for business model and "machine-readable privacy terms" - See new deck https://kantarainitiative.org/confluence/download/attachments/17760302/IEEE%... and info about IEEE P7012 http://sites.ieee.org/sagroups-7012/ Andrew has been a program manager in IEEE. A "P number" (P7012) is a program number. The society it's in (SSIT) is the sponsoring organization, in this case Society for Social Implications of Technology. This group is "SSIT/SC/MachReadPrivacy". This will meet periodically as defined by the group, produce a draft, etc., as determined by the chair's abilities. Eve showed the latest status of our mappings https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7... (see callout numbers in panels) from legal party roles to technical artifacts. There are a few questions outstanding, shown in red. David described his new potential use case tied to the Personal Information Protection Company (PIPC) framework in the new Vermont law. Oliver Goodenough has indicated interest related to the insurance industry. Vermont is a well-known captive insurance market, and David anticipates that UMA could be a great ready-made solution. The law also creates a Blockchain-Based LLC (BBLLC) framework adjacent to a PIPC. Regarding data privacy and consumer protection, the goal is to come down on the side of consumer protection. If there is any additional work needing to be done, not statutory rule-making (an act passed by the legislature but other regulatory guidance around S.269), we've got some willingness there. For the captive insurance industry, a big question is: What would the "identity topology" look like that underlies the UMA authorization topology? This would determine the most friction-free and viable UMA deployment topology. For example, would an insurer-as-AS be a relying party on federated logins from their customers-as-RS's? Or is there self-insuring by large companies (or maybe single sign-on is happening anyway there?). If blockchain is being used, is blockchain identity (e.g., with Verifiable Credentials) somehow involved? Note that organizing a PIPC in Vermont doesn't disrupt an existing (or new) organization's business. Andrew asks: Would SphereIdentity or Meeco be interested in knowing about this opportunity? Thanks to Tim for spurring the initial conversation around the law! Next steps: Schedule an ad hoc meeting with the principals who may spur a demo project. Future meeting schedule We've already got *Aug 30* down as *canceled*. We also *won't meet Sep 6*, due to its being during the week of US Labor Day. However, we'll go back to a *weekly schedule starting on Sep 13*, only canceling when there aren't enough items on the agenda. New blog post If you like, feel free to publicize this post https://www.forgerock.com/blog/why-user-managed-access-essential-creating-tr... about the Origo (financial services) UMA use case! Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Maciej 4. Eve 5. Mike Non-voting participants: - Andrew - Bjorn - Tim - David - George - Colin Regrets: - Cigdem *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl