2018-02-09

Attending: Eve, Tim, Bjorn, Kathleen

We don't yet have Tim in a WG leadership team role with a title! And he really deserves one.   How about something like "legal adviser"? Let's bring that up at the next whole-of-WG call.

AI: Eve: Bring up a motion on the next WG call about Tim's leadership team role.

We made further tweaks to the 2018 charter refresh proposal to reflect the Legal work stream.

There's general agreement that the Consent Receipts format, so far, accounts for general opt-in consent as known and used today, but it doesn't account for the kind of scope-grained, asynchronous consent/authorization/policy setting and withdrawal that UMA enables.

Things to consider in our business model: Can the ASO be a true Agent even in the use case where the ASO is, say, your IdP and wants to be your trusted AS, but doesn't hold any of your personal data? All your protected resources are held in third-party RS's, so the AS hooks up with them through PATs (OAuth) in an overt way. The challenges would be that the ASO can still learn about:

• Which RS's Alice uses (Schwab vs. Fidelity) – could be tempted to sell this information to advertisers
• Some notion of the nature of the protected resources, through the metadata uploaded as part of resource registration (e.g., see the HEART profiles, which point to FHIR Resource types) – would know what resource is an EHR – could be tempted to sell this information
• The requesting parties associated with Alice and information about them (graphs of relationships), to the extent of whatever claims were collected – if the ASO isn't Facebook or Facebook-based claims aren't collected, this presumably limits the scope of discovery of who everyone is, but the risk is there

The theory is that these risks could be managed much better in the case of a "personal authorization server" (which is what Adrian and Michael Chen have built into their HIE of One implementation) because the ASO's business model would not have to compromise for its single resource owner. Perhaps it's as simple as the "pie chart" showing the ratio of money-to-data-to-attention that the resource owner pays the service. If a SaaS company offers an AS to millions of potential ROs, and the business model is such that the ROs don't have to pay any money outright, then it's really hard for the ASO to be a true Agent. In other scenarios where the AS and the RS (or one of the RS's) are colocated, then the ASO is already "compromised" by this:

• The ASO-that-is-also-the-RSO holds some/all of Alice's resources and thus can see that data (so "trust mitigations of trust attacks" – auditability of these relationships – may be needed)

Further, if the ASO also runs the client (or one of the clients) that the RqPs use, then the ASO is already "compromised" by this:

• The ASO-that-is-also-the-CO is gaining access to resources using tokens it issued itself (so "trust mitigations of trust attacks" – auditability of these relationships – may be needed)
  • Kathleen notes that they have been discussing signing of contracts

Tim can join the WG calls as needed for when we combine this work with overtly technical topics. Kathleen (and Mohammad) generally can't join the Thursday calls, so we can either schedule ad hocs as necessary or perhaps use the Legal call time as necessary.

(A reminder: Our "Legal role definitions" deck is here. The paper will be published officially by next week, but you can also find the unofficial version, which has all the diagrams, in our mail archives here.)

AI: Eve: Ask colleagues if their health IoT storyboard could be used as a starting point for the POC idea.

AI: Eve: Reach out to Jim Hazard to alert him to the POC idea.