- WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2018-10-04
by Eve Maler 04 Oct '18

04 Oct '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-04 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2018-09-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20>: Deferred. Update on PIPC/captive insurance discussions if available Next week we plan to have a meeting, or maybe multiple meetings, related to PIPC. Vermont's AG is looking at a project involving a "regulatory sandbox" (was it called "FCA"?). Update on interop testing activities if available Prabath is able to join the *Oct 18* WG call to do a demonstration of the WSO2 UMA2 implementation. By then we should hopefully have a better idea of matrix tests and even some published blog posts from the various testers. Does the June 2019 Identiverse timeframe make sense for thinking about an interop event? Yes, likely. Eve and Andi can discuss offline. Colin also hears of additional vendor interest. Discuss Adrian's notification use cases - See last email in this thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/DpK9SmN2T…> Adrian's proposed use case text is reproduced below. This is all related to notifications. Let's discuss, analyze whether they're solvable with "UMA today", and if not, what the next steps are. *1 - Alice (RO) needs to be notified by the RS that the RS has ignored or modified an AS scope. (This is the Adrian Clause)* Another way to state this (more technically stated) is that the RS receives an RPT from the client (that the AS correctly issued), determines what resource IDs and scopes are associated with it, and then chooses to act in a way contrary to the scopes listed for a specific resource ID. (Either fewer scopes – more constrained – or more scopes – less constrained.) The latter is a sort of hard form of "break-the-glass", meaning that there was never an RO policy allowing that much scope. (We discussed this in the UMA Legal subgroup with a decision-tree approach on 2016-01-15 <https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…> .) You can consider the knowledge of whether the access was given to be part of the equation of "Accounting of Disclosures". This topic is most often associated with healthcare security/privacy, but also has implications for other data protection regulations such as GDPR. The RS is exclusively in a position to know whether it gave access. However, it could inform the AS (and rely on the AS to tell the RO) vs. telling the RO directly. What are the timeliness requirements of this notification type? It doesn't seem strongly sensitive. What are the channels by which the RS could communicate its activity to the RO? - 1. The RS presents some app to the RO for managing resources; that app is outside the scope of UMA. (E.g., a photo service/app would have to develop its own notification functionality, or a patient portal would have to develop its own notification functionality, anytime the "Adrian clause" were invoked.) The RS app would be the one to produce notifications of RS behavior upon choosing the "anomalous case" regarding giving clients access after receiving an RPT, vs. the "normal case". For that matter, notifications/log entries could be produced anytime access were granted in the normal case too. Some implications: 1. Each RS app produces such notifications independently, rather than enabling centralization (aggregation?) of such notifications. 2. Each RS can guarantee that it has produced a notification of its own true behavior. 2. The AS (or the service presenting a standardized UMA protection API to RS's, that is, an AS interface) presents in addition some notification endpoint – which doesn't yet exist – to UMA RS's so that they can report details of their access-giving behavior to that endpoint. The intention is for that service to become the aggregated notification-producing service for the RO. Some implications: 1. The notifications now come from a single service, vs. potentially multiple independent apps. 2. Each RS now must rely on that central service to relay/make available the details of the access-giving behavior to the RO. Did the previous implementation that Maciej has demonstrated show an RO notification flow? *2 - Alice (RO) needs to be notified by the RS that the Client presented to the RS is deemed inadequate for automated registration and Alice herself, not Alice’s AS, must acknowledge the warning by the RS in order for the Client access to proceed. (This is the current interpretation of HIPAA for patient-directed exchange)* This notification type has strong timeliness requirements. *3 - Alice (RO) needs to be notified by the AS that a RqP has presented with a query for registered resources. (This is where someone other than Alice invites the RqP to access her resources without specifying a particular resource).* See 38:00 in the Google TechTalk video <https://www.youtube.com/watch?v=91RUONg6po4> for a demo of this from way back. We have additional implementations, probably with a variety of approaches: API endpoints, web hooks, etc. We may want to compare approaches and see if there's any motivation to standardize for interop. *4 - An RS or an RqP wants to notify Alice of something but they only have the service endpoint of Alice’s AS. (Alice is using the AS as a blind drop the way she might use a dating app)* To be continued. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Andi 3. Eve Non-voting participants: - Adrian - Colin Regrets: - Nancy - Maciej *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2018-10-04
by Eve Maler 03 Oct '18

03 Oct '18

(I think some other use cases/user stories may come in also.) https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-04 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2018-09-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20> - Update on PIPC/captive insurance discussions if available - Update on interop testing activities if available - Discuss Adrian's notification use cases (see last email in this thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/DpK9SmN2T…> ) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-09-20
by Eve Maler 26 Sep '18

26 Sep '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-08-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-23>, UMA telecon 2018-09-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-13>: APPROVED. Update on PIPC/captive insurance discussions and next steps over the next couple of months Eve and David will coordinate at CIW tomorrow on setting up the initial meeting with the insurance contact. Update on interop testing activities Keycloak deployed an instance for Gluu to test against. They didn't test claims gathering, but they tested everything else, and after some effort, they got things working. There were some issues around client registration, which is sort of out of UMA's scope. Gluu was using dynamic client registration. The Keycloak engineer is going to do a writeup. The RS/C interaction wasn't working at first. Mike has also written to Prabath of WSO2 to suggest doing interop testing, and the latter indicated interest. WSO2 has apparently finished their UMA2 development. They're not supporting claims gathering either. Why might this be? Mike sees claims gathering as useful for collecting consent etc. Eve surmises that this is an outgrowth of the two distinct use cases hinted at by the "assertion flow" vs. "authorization code flow" design patterns hidden within the claims collection model expressed in the UMA grant (see Bertrand's post <https://www.riskinsight-wavestone.com/en/2018/09/demystifying-uma2/>). Cigdem sees claims gathering as optional, and some vendors are just doing what's mandatory at first. Adrian notes that SSI is all about how you encode and present credentials. The VC (verifiable claims/credentials) group is doing this, and HIE of One implements this (Michael Chen confirmed to Eve that the implementation uses uPort at the claims gathering endpoint). HIE of One is also interested in interop testing, and suggests that doing this is important for adoption, e.g. with Medicare, so that it can certify client apps. Eve has begun talking to ForgeRockers about this as well. Eve discussed the status of all this work with the Leadership Council yesterday, and pointed them to our old UMA1 interop testing wiki area <https://kantarainitiative.org/confluence/display/uma/UMA1+Interop+Results> (link goes to the results matrix; see the additional links near the top of the page). The matrix currently assumes that participants don't test "role against role" within their own solutions, but perhaps we should do that, since, e.g., an AS and an RS should indeed work as independent functions/roles. Update on CIBA/UMA discussions Mike and Eve had a discussion about extending the notification options for UMA through a simple extension spec. Mike's concern is that since CIBA at base has a foundation on federated identity/authentication, it may not be fully appropriate to solve the set of use cases. Bjorn notes that there was heavy discussion around the philosophical question of authorization and authorization(approval)-by-authentication. But there are multiple ways to do things. So it should be fine to try and solve the use cases in what we see as the most appropriate way. Eve's biggest question is around multi-party delegation of access. Another extension Mike is keen to explore is scope expressions. The WG just requires some "language to look at" so we can consider the extension properly. Starting an extension doc in xml2rfc format could just copy one of our existing specs <https://github.com/KantaraInitiative/wg-uma> and gut whatever isn't needed. The XSLT stylesheet is in the util subdirectory <https://github.com/KantaraInitiative/wg-uma/tree/master/util>. Let's just call this "*decoupled*", not "CIBA/UMA". In our next meeting (*Oct 4*) we'll look at specific flows. Adrian also speaks up for working on notification more, for his own purposes. Since in his use cases the RO controls the AS, it's necessary for the AS to act as the agent of the RO in the right fashions. *AI:* Adrian: Write some user stories to characterize the requirements for RO notifications. Eve and her folks have been working on a way to send notifications to requesting parties that a resource has been shared with them, where possible. Perhaps this is something we can compare notes on eventually and capture as a best practice, or even standardize. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Eve 3. Mike 4. Cigdem Non-voting participants: - Bjorn - Adrian - Nancy Regrets: - Tim - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Agenda for UMA telecon 2018-09-20
by Eve Maler 20 Sep '18

20 Sep '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2018-08-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-23>, UMA telecon 2018-09-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-13> - Update on PIPC/captive insurance discussions and next steps over the next couple of months - Update on interop testing activities - Update on CIBA/UMA discussions - Reminder: no meeting on Sep 27 - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Intro
by Chris Olsen 13 Sep '18

13 Sep '18

Hello UMA-WG, An introduction of myself at Eve's request. My name is Christopher (Chris) I come from the land of green as in emeralds. Guess my city. I have been an Identitarian since 2007 ish and am fascinated and amazed at the progress the industry has made over the years, but also disappointed in how few people even know its a thing, knowing identity it is the backbone of all or our digital existence. I started out in all of this as the SAML guy because I was the only one that could almost spell it :-) Anyway, I have my roots in very large airplane/ defense industry and now in entertainment with mice. Some of you I know, some I know of, and many I do not know; but looking forward to fostering friendships and professional bonds with all interested. Eve has been working on UMA for quite a while, I have read stuff and followed a little, but I do not understand it beyond the top layer. I hope to learn more and maybe help bring the standard into the light, contributing where I can. Best regards, Christopher Olsen

1 0

Draft minutes of UMA telecon 2018-09-13
by Eve Maler 13 Sep '18

13 Sep '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-13 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-08-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-23>: Deferred. General discussion Tim is working with an EC-funded identity project and has become aware of a project in Azerbaijan related to digital identity, a bit similar to efforts in Estonia. Others on the call have not. Interesting. Heads up – no meeting in two weeks, on Sep 27 The calendar invitation has been removed. Eve is traveling. Updates on the UMA world and other relevant worlds (OAuth, OB...) – any appetite for extensions this year? Bertrand Carlier's blog post is here <https://kantarainitiative.org/confluence/pages/editpage.action?pageId=10459…>. As previously discussed, his insight about the OAuth grant flows available within the UMA2 grant flow is a good one. And as Justin has observed, it would be valuable for OAuth to have a formal model for grant flows the way UMA and other specs do, with a permission ticket pattern and all. Mike asks: What's the action item? Is there something worth "factoring out" that could be absorbed by the wider community? Putting a pin in that question for a second... When we first looked at the decoupled use cases and how CIBA and UMA might variously satisfy them, we observed that neither seemed truly complete and maybe piece-parts could be combined. Mike suggested "UMA-protecting" the /bc-authorize endpoint. The CIBA spec is now going through a modularization process, into a core and at least one profile. (Let's assume Alice is the RO and bank customer, and Bob is the RqP and agent.) There is a need for asynchronous approval by Alice. To what degree is Alice's identity/her claims required to be proved (authenticated) to Bob and some service representing him (say, an IdP)? The decoupled use cases do expect this, and that's the premise behind using OIDC as the basis behind CIBA. The core would have the notification modes. We understand that there will be three different notification modes: poll mode, ping mode (you get back a reference ID), and push mode (you get back a token directly). We understand that polling is considered most secure but insufficient for some use cases. Quoting here: - *Poll Mode - When configured in Poll mode, the Client will poll the token endpoint to get a response with the tokens. * - *Ping Mode - When configured in Ping mode, the OP will send a request to a callback uri previously registered by the Client with the unique identifier returned from the Backchannel Authentication Endpoint. Upon receipt of the notification, the Client makes a request to the token endpoint to obtain the tokens. * - *Push Mode - When configured in Push mode, the OP will send a request with the tokens to a callback uri previously registered by the Client.* Would we need to create an extension (beyond "poll mode", which we already have)? Eve: Right now only Bob's client is inside the protocol's scope. The user agents that Alice uses to interact with the AS and the RS are "internal" and aren't part of the protocol. Mike: There are multiple APIs, so yes, it's a challenge that UMA is not entirely "reciprocal". The "manage (out of scope)" notation at the RS and "control (out of scope)" notation at the AS in the FedAuthz diagram are the oddities. Nancy: In her company's work (healthcare), they have noticed that Alice's and Bob's roles could be switched. Eve: If we have to expose proof of Alice's authentication to Bob's service, can we do it with some workaround by leveraging the fact that the PAT requires use of the AS's OAuth authorization endpoint and – ideally – production of an OIDC ID token as well? (We do advise in FedAuthz <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0…> that if identity is needed in addition to access, a PAT should also use OIDC.) Mike: Really don't think that's necessary. CIBA Core is expected to have a first Implementer's Draft by mid-October, so let's take a look then. Mike is strongly encouraged to play around with an UMA-decoupled swimlane soon, so we can get our heads around this more firmly. We're just a bit concerned that some big challenges of party-to-party delegation will be missed if an "authentication-only" approach is taken to the decoupled use cases. If we can do our analysis during the same period that the CIBA Core spec is being worked on and also reach out to key CIBA driving forces (Dave Tonge, Brian Campbell, Don T, Nat) with the ideas and results, maybe we can find a way to work together. Eve: Work with Bjorn on reaching out to Dave, Brian, Don, Nat on CIBA and UMA. Interop activities Mike/Gluu has been making progress on interop with RedHat Keycloak. Update on PIPC/captive insurance discussions and next steps over the next couple of months Deferred until David can join us. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Eve 3. Mike 4. Cigdem Non-voting participants: - Scott - Tim - Bjorn - Nancy Regrets: - Andi - Maciej - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Agenda for UMA telecon 2018-09-13
by Eve Maler 12 Sep '18

12 Sep '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-13 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2018-08-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-23> - Update on PIPC/captive insurance discussions and next steps over the next couple of months - Updates on the UMA world and other relevant worlds (OAuth, OB...) – any appetite for extensions this year? - Heads up – no meeting in two weeks, on Sep 27 - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Great post from Bertrand Carlier on UMA2
by Eve Maler 11 Sep '18

11 Sep '18

https://www.riskinsight-wavestone.com/en/2018/09/demystifying-uma2/ Feel free to get the word out -- for example, retweeting @betrandcarlier and/or @UMAWG... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Re: [WG-UMA] Thank you for signing the Kantara GPA
by Maciej Machulak 09 Sep '18

09 Sep '18

Hi Satish, Very nice to e-meet you. I am glad that you are interested in the UMA protocol. I would be keen to learn how/if you see the use of this protocol for your use cases. It would be great if you could join one of the calls and provide an introduction! Cheers, Maciej On Sun, 9 Sep 2018 at 16:33, Hadimani, Satish <satish.hadimani(a)owasp.org> wrote: > Hi Eve, > > Thanks for your email, > > Link to my profile <https://www.linkedin.com/in/hcsatish/> and based in > Bangalore - India, working with Security Service Organization. Brief > profile summary "*Having around 20 years of experience in the Software > industry and with 15 years of experience in Identity and Access > Management" * > > Am following UMA specification almost from UMA's initial days and sessions > especially from you and Maciej Machulak. As I found this is protocol will > be a beginning to permission control gate spread across different kind of > systems. > > As working with different timezone clients, most of the times will be busy > with project calls, hence challenging to attend the regular meetings (which > fits into my evening). > > My detail as below, > email - satish.hadimani(a)owasp.org > Skype - @hcsatish > > Finally apologies for the delayed response. > > Regards, > > -- > > Satish > > > On Fri, Aug 31, 2018 at 7:43 PM Eve Maler <eve(a)xmlgrrl.com> wrote: > >> Hello Satish, >> >> Apologies for sending this message so tardily. Welcome to the group! >> >> We invite you to send a note of self-introduction to the >> wg-uma(a)kantarainitiative.org list. We generally meet on Thursdays >> (through our summer schedule has been slower), and I tend to send out >> agendas a day or two prior. Here's the UMA online calendar: >> http://kantarainitiative.org/confluence/display/uma/Calendar >> >> We do our work in both of the following locations: >> >> http://kantarainitiative.org/confluence/display/uma >> https://github.com/KantaraInitiative/wg-uma >> >> Let me know if you’d like me to add you to the online calendar invitation >> to help you remember to attend (though regular attendance is not mandatory >> for non-voting participants). Also, let me know your Skype handle if you’d >> like to be added to our Skype chat room where we alert people to upcoming >> meetings and the like. (Our Slack team doesn’t seem to get much use, but >> let me know if you’re interested in it.) >> >> Best regards, >> >> Eve >> UMA WG chair >> >> >> >> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl >> >> >> On Mon, Jul 16, 2018 at 6:57 AM, <bella(a)kantarainitiative.org> wrote: >> >>> Dear Satish Hadimani, >>> >>> Thank you for signing the Group Participation Agreement (GPA) to >>> participate in the User Managed Access WG. Your application/agreement has >>> been received and approved. You are also now subscribed to the listserv so >>> you can send and receive group emails and browse the discussion group >>> meeting notes, calendar of events, roster, etc. so you can participate at a >>> basic level. Remember, the GPA is only valid for your current employment >>> (if representing your employer) or current email address. If either of >>> these change, you must Contact Us >>> <https://kantarainitiative.org/contact-us/> so we can remove your >>> details. Of course you may re-sign another GPA with the updated details. >>> >>> The information in this next paragraph below, relates to participants >>> who wish to create a user account to access Confluence, Kantara’s >>> collaboration tool add or edit content on the group wiki. For group >>> officers (Chair, Co-Chair, Vice-chair, Secretary, Editor) this will be >>> required. For others, it is optional and you can browse anonymously as per >>> the paragraph above. >>> >>> To create an account and get full access to the Kantara Wiki, please >>> click here. >>> <https://kantarainitiative.org/confluence/display/GI/Create+an+account+and+g…> >>> To manage your password for the Kantara Initiative IdP, login at >>> https://idp.kantarainitiative.org/ and change it there. Then, your >>> update will be reflected on the Kantara Initiative Confluence Wiki site. >>> If you use an alternative Identity Provider, the passwords are managed at >>> the respective IdPs and not with Kantara Initiative, please find more >>> information here >>> <https://kantarainitiative.org/confluence/display/GI/Logging+in+with+a+third…> >>> on how to login. >>> >>> Please let me know if you have questions, we look forward to your >>> participation with the group! >>> >>> Best regards, >>> >>> Isabella >>> >>> *Isabella Novais* >>> Kantara Initiative, Inc. >>> Membership Administrator >>> bella(a)kantarainitiative.org >>> >>> [image: Kantara-Logo] <https://kantarainitiative.org/> >>> >>> *Information for WG Chair Below:* >>> >>> - Name: Satish Hadimani >>> - Title: N/A >>> - Company: N/A >>> - Group: WG - User Managed Access >>> - Voting status: non-voting >>> >>> >>> >> >> -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +48 602 45 31 66 (PL)

1 0

Draft minutes of UMA telecon 2018-08-23
by Eve Maler 24 Aug '18

24 Aug '18

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-7…> , 2 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-2o4_QY-H…> ) 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/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> (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-t…> 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

1 0