...
- Fridays, 8-9am PT
- Screenshare and audio: http://join.me/findthomas
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2017-06-09
- Reviewing pieces of deliverable #3
Attending: Eve, Colin, Tim, John W, Mark L, Kathleen
The new matrix maps UMA consent licenses to key concepts in various regulatory regimes. How can we vet the correspondences? Can we see UMA as another chapter in the millennia-old commercial legal system?
"Open" licenses are freely transferrable. "Limited" licenses limit the use to one specific user. Tim threw in duration as well, under "Non-Transferable". John points out that stopping the usage at one stop could be problematic because then a data controller couldn't ever go on and share with a data processor.
Scenario: RO Alice chooses to share certain files (say, scanned receipts) from digital file system service Dropbox (an RS) to accountant (RqP) Bob, where Bob is using client app TurboTax. (Alice also happens to use TurboTax sometimes.) Alice's AS is ShareHub.
Eve's question is: Is Bob a Data Processor? Or is Bob another Data Controller? Could there be different licenses for either circumstance?
Regarding our artifacts:
- The PAT (where Alice's AS and RS, ShareHub and Dropbox in this case, get associated together) is an OAuth access token, so it's an opt-in flow where Alice (typically) has no choice about the terms. The reason this may matter is that we might have limited ability to affect OAuth's parameters of a "legal framework", vs. UMA's.
- On the other hand, the RPT (where Alice's policy conditions dictate the specific permissions and their durations) has a more discretionary nature. She has choice and control, to the extent of the AS's policy condition capabilities. (Those capabilities are in the "competitive space". See UMA Grant Sec 3.3.4, second Note text. This allows AS's to compete on policy condition handling.)
- The PCT probably doesn't have any of the same categories that the PAT and RPT have. It's a simple token, actually a OAuth-like, which would have different rows.
Is there always, sometimes, or never a transfer of accountability where the RqP becomes another Data Controller? The use cases we collected earlier, to her mind, seem to include both kinds. Mark brings up the case of consenting to sharing data for marketing purposes in this context. Kathleen thinks consumers won't get subtleties (and Eve agrees). Getting alerts would be a good pattern in case of concerns.
So, apparently, our analysis seems to hold! We'd like to vet all this against the columns of the matrix. ("Consumer Data" refers to the body of commercial law.) Including the parental consent pattern would be good as well; it doesn't have to be specific to any one law/regulation.
- Our presumption is that UMA is about the Resource Server Operator being a Data Controller serving the Data/Resource Subject (under some complex regime of the Data/Resource Subject's proxy, the Resource Owner, and their agent, the Authorization Server Operator).
- We think we have to cover both "sharing with/delegating access to" a Data Processor (someone with limited accountability/responsibility/liability because they're getting access under your control) and another Data Controller (someone with full accountability/responsibility/liability because they're getting access on their own recognizance). We assume that AS and RS competition on interfaces for policy, resource types, etc. will need to ease paths for resource owners who interact with them.
Kathleen asks: How to distinguish a license from a contract? Traditionally, a data subject isn't really given the opportunity to control what's done with their data. Eve: A license is a kind of contract/agreement, right? Mark notes that the CIS group today did a lot of great work around the FIPPS. They stress "...with the consent of the data subject". Discussion ensued about the role of the original principles, further operationalization in the DPD and then the GDPR, and the concurrent rise of the OAuth, OIDC, and UMA stack and Consent Receipts. We also discussed the Brave Browser and their recent huge round of funding.
Kathleen provides a link to a presentation from HIMSS about VA and UMA.
AI: Eve: Send out links to the current state of the (old) Binding Obligations and (newer) CommonAccord model clause text, which was intended to fill in PAT and RPT license text (and on and on), respectively.
AI: Eve and Tim: Meet briefly to brainstorm what rows the PCT would have, and external experts to reach out to.
AI: All: Review the X's in the cells of the matrix. (Eve will email the Word file to make this possible.)
2017-05-26
- Reviewing deliverable #2
...