Quorum was reached.
Approve minutes of UMA telecon 2018-08-09: APPROVED.
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.
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 (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.
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.
If you like, feel free to publicize this post about the Origo (financial services) UMA use case!
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)
Non-voting participants:
Regrets: