...
- Fridays, 8-9am PT
- Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines / web interface, code 178-2540#
- Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2016-12-16
- Use case/mapping exercise
- Toolkit discussion: roadmap?
- Legal as a WG vs. a subgroup
Attending: Eve, John W, Ann
Could a PIA be a target for a "toolkit"? John does a lot of these. There are lots of standard forms. ISO is working on one. A PIA is a tool for evaluating the policies and practices of an entity wrt a given standard (law, directive, etc.). So to the extent that you can log that a particular technical interop standard such as UMA or OTTO or whatever has been used, it's likely that this is necessary but insufficient. Under accountability, you should appoint a DPO, you should have contractual elements so that transferring data to a processor has valid and correct safeguards, etc. Eve is imagining that if we have produced some model text and it's versioned, jurisdiction-specific, etc., then an entity that actually uses it as a "toolkit" is in a good position to also use a subsidiary "PIA toolkit" in efficient fashion to get a leg up on compliance. Our toolkit work is precisely intended to be the "BLT stack" that fills in enough real-world deployment pieces above the technical standard to be interesting.
Make this a separate WG vs. a subgroup? It's effectively a parallel group already, without the logistical overhead. It does want to produce "real specs". Our intent is to boil a smaller pond if anything rather than open up to new charter implications, while still being open to the appropriate extensibility points that would allow for things like consent receipts (and maybe other similar proofs of consent), UST (and maybe other similar), etc. to be referred to. The default is to keep everything the same for now.
The axes of use case development actually look more like this:
- Data subject vs. some proxy for them granting access
- Granting access to a resource that is not individually but jointly "owned" in some fashion (e.g. genome)
- Complexity of party that was granted access (employee of organization, individual acting on own behalf, organization itself...)
- Task-based access grant or control-sharing access grant
- Does anything about this change if some "non-HTTP-GET" operation is used (i.e., the client and requesting party aren't being "disclosed to" but are actively operating on the server's contents – inserting or deleting)?
- Fiduciary role of the operator of the AS (SaaS, personal, enterprise)
- Jurisdictional location of the grantor/data subject/grantee (with any complexity)
- Matters to operator of the RS for their data transfer accountability
- Might matter to operator of the client for their data transfer accountability if "non-HTTP-GET" scenarios matter?
- Sector-specific and other use-case-specific details
The UMA scope mechanism isn't a good match for purpose limitation because the RO would want to differentiate "user-submitted terms" per grantee. But some factored-out legal text might actually be appropriate to add to scope description documents as metadata, at least in the case of "disclosure-oriented" scopes, depending on how our analysis of use cases comes out!
We still have toolkit roadmap work to do. That would be appropriate after more use case/mapping work.
2016-12-02
- Use case collection and impact on concept mapping
- End-of-year planning and news
...