Standards Committee Teleconference 2008 08 13: Difference between revisions
Joe.andrieu (talk | contribs) (New page: ==Standards Committee Teleconference Call Notes== Drafted by Joe Andrieu, August 13, 2008 ==Other Calls== Category:Standards Committee Teleconferences [[:Category:Standards Committee ...) |
|||
| Line 21: | Line 21: | ||
==Notes== | ==Notes== | ||
===Volunteered Personal Information=== | ===Volunteered Personal Information=== | ||
This is a meta-layer for all sorts of data types. A general framework. Allows the individual to have their own Privacy Policy, which companies or governments would have to accept. | |||
This is a meta-layer for all sorts of data types. A general framework. Allows the individual to have their own Privacy Policy, which companies or governments would have to accept IF they wish to access this data. | |||
Within that, you'll have multiple different types of data, each with potentially different policies. | Within that, you'll have multiple different types of data, each with potentially different policies. | ||
| Line 33: | Line 34: | ||
Recent develpments with Markey in US Congress re: Behavioral Data. | Recent develpments with Markey in US Congress re: Behavioral Data. | ||
Behavioral data is definitely one of the 90 data types... looking at the Trust Index. Currently, the average trust index score today is about 55, but we expect users would require | Behavioral data is definitely one of the 90 data types... looking at the Trust Index. Currently, the average trust index score today is about 55, but we expect users would require 70 or better. So, companies would need to behave significantly differently in their data handling and use to be allowed to access the VPI. | ||
Trust index is more about compliance--users will still likely have specific requirements. | Trust index is more about compliance--users will still likely have specific requirements. | ||
At the moment the current privacy | At the moment the current privacy legislation doesn't go to enough detail. | ||
In a VPI share scenario, the iteration will be more akin to: | |||
"Ok, you wish to access my XXX data, between this date and that date, and you are going to use it for four things and NOT these 23 things." | "Ok, you wish to access my XXX data, between this date and that date, and you are going to use it for four things and NOT these 23 things." | ||
| Line 46: | Line 50: | ||
Either Higgins/Infocard or Liberty, in terms of access privileges. | Either Higgins/Infocard or Liberty, in terms of access privileges. | ||
A major issue is that once you release the data, you've lost control (with the old paradigm). The Liberty/Infocard technologies can enable | A major issue is that once you release the data, you've lost control (with the old paradigm). The Liberty/Infocard/ Higgins technologies can enable seamless use of data with robust access privileges, bound with good policies. | ||
Not traditional media "DRM" in terms of wrapping bits it crypto packets... but looking at a higher level. | Not traditional media "DRM" in terms of wrapping bits it crypto packets... but looking at a higher level. That said, DRM might be appropriate for very specific data types. | ||
Right now, Iain is buying a new car. There are seven different car companies/dealers that have Iain in their sites, each with a % guess that he is in the market. So, Iain is stuck dealing with the deluge of junk mail, because there isn't a single repository for an authoritative source of his current intention. | Right now, Iain is buying a new car. There are seven different car companies/dealers that have Iain in their sites, each with a % guess that he is in the market. So, Iain is stuck dealing with the deluge of junk mail, because there isn't a single repository for an authoritative source of his current intention that can release that under his terms. | ||
The technology is really about access, policy, and auditing (APA). NOT about protecting the bits, but about building a framework for compliant access to the bits. | The technology is really about access, policy, and auditing (APA). NOT about protecting the bits, but about building a framework for compliant access to the bits. | ||
| Line 58: | Line 62: | ||
So, there are two different components: one is about APA, the other is about interoperability so that the different data types can be seamlessly sent from user to and compliant vendor (and vice-versa). | So, there are two different components: one is about APA, the other is about interoperability so that the different data types can be seamlessly sent from user to and compliant vendor (and vice-versa). | ||
Ultimately, there will be twelve components of the program. Of the twelve questions in the trust index, eight of them are from EU privacy law, and four are from VRM conversation. | Ultimately, there will be twelve components of the program. Of the twelve questions in the trust index, eight of them are from EU privacy law (which is pretty much the same as Canadian and Australian), and four are from VRM conversation. | ||
How do we avoid the inevitable rabbit holes of debating data formats while establishing the | How do we avoid the inevitable rabbit holes of debating data formats while establishing the framework? | ||
So we don't need to solve all the data types at first. The CIC will be | So we don't need to solve all the data types at first. The CIC will be piloting this stuff from around January 2009. It doesn't need standards. It knows what data to offer up. | ||
We want to make it clear that the APA needs a data-agnostic approach. Ideally, this would be something like MIME attachments for email, where MIME specifies how you attach any kind of data to an email, and the MIME types deal with individual data types and how they are encoded. Similarly, the APA framework deals with how one accesses any kind of data, and APA Datatypes would specify the formats and semantics of particular data. | We want to make it clear that the APA needs a data-agnostic approach. Ideally, this would be something like MIME attachments for email, where MIME specifies how you attach any kind of data to an email, and the MIME types deal with individual data types and how they are encoded. Similarly, the APA framework deals with how one accesses any kind of data, and APA Datatypes would specify the formats and semantics of particular data. | ||
| Line 69: | Line 73: | ||
[NOTE: terminology is all strawman. It made sense during the call, but may not fit long term.] | [NOTE: terminology is all strawman. It made sense during the call, but may not fit long term.] | ||
===CIC will be looking for sponsorship=== | ===CIC will be looking for sponsorship=== | ||
Soon, the CIC will be announcing a project to research VPI standard and will be talking with large companies to fund it. | Soon, the CIC will be announcing a project to research VPI standard and will be talking with large companies to fund it. | ||
Latest revision as of 01:38, 14 August 2008
Standards Committee Teleconference Call Notes
Drafted by Joe Andrieu, August 13, 2008
Other Calls
Category:Standards Committee Teleconferences
Attendees
- Joe Andrieu
- Iain Henderson
Previous Action Items
- Additional thoughts to one night stand notes to VRM wiki. Eve. By next Wednesday.
- Close loop with and Doc and finalize Oct mtg date. Joe. By next Wednesday.
Agenda
- Set Agenda
- Review previous Action Items
- Review Action Items
Notes
Volunteered Personal Information
This is a meta-layer for all sorts of data types. A general framework. Allows the individual to have their own Privacy Policy, which companies or governments would have to accept IF they wish to access this data.
Within that, you'll have multiple different types of data, each with potentially different policies.
5 or 6 standard policies, ala Creative Commons, human and machine readable.
At least 90 types of data, categories with potentially different types of privacy policy.
Iain sees about a year of a public process to generate a viable specification.
Recent develpments with Markey in US Congress re: Behavioral Data.
Behavioral data is definitely one of the 90 data types... looking at the Trust Index. Currently, the average trust index score today is about 55, but we expect users would require 70 or better. So, companies would need to behave significantly differently in their data handling and use to be allowed to access the VPI.
Trust index is more about compliance--users will still likely have specific requirements.
At the moment the current privacy legislation doesn't go to enough detail.
In a VPI share scenario, the iteration will be more akin to:
"Ok, you wish to access my XXX data, between this date and that date, and you are going to use it for four things and NOT these 23 things."
And there would be both technical parts to enforce these uses and policy parts.
Technical?
Either Higgins/Infocard or Liberty, in terms of access privileges.
A major issue is that once you release the data, you've lost control (with the old paradigm). The Liberty/Infocard/ Higgins technologies can enable seamless use of data with robust access privileges, bound with good policies.
Not traditional media "DRM" in terms of wrapping bits it crypto packets... but looking at a higher level. That said, DRM might be appropriate for very specific data types.
Right now, Iain is buying a new car. There are seven different car companies/dealers that have Iain in their sites, each with a % guess that he is in the market. So, Iain is stuck dealing with the deluge of junk mail, because there isn't a single repository for an authoritative source of his current intention that can release that under his terms.
The technology is really about access, policy, and auditing (APA). NOT about protecting the bits, but about building a framework for compliant access to the bits.
And discovery, machine readability. (Is this inseparable from the APA?)
So, there are two different components: one is about APA, the other is about interoperability so that the different data types can be seamlessly sent from user to and compliant vendor (and vice-versa).
Ultimately, there will be twelve components of the program. Of the twelve questions in the trust index, eight of them are from EU privacy law (which is pretty much the same as Canadian and Australian), and four are from VRM conversation.
How do we avoid the inevitable rabbit holes of debating data formats while establishing the framework?
So we don't need to solve all the data types at first. The CIC will be piloting this stuff from around January 2009. It doesn't need standards. It knows what data to offer up.
We want to make it clear that the APA needs a data-agnostic approach. Ideally, this would be something like MIME attachments for email, where MIME specifies how you attach any kind of data to an email, and the MIME types deal with individual data types and how they are encoded. Similarly, the APA framework deals with how one accesses any kind of data, and APA Datatypes would specify the formats and semantics of particular data.
So, in essence APA is like a VRM Mime Type for volunteer personal information, and Iain already has identified at least 90 APA datatypes.
[NOTE: terminology is all strawman. It made sense during the call, but may not fit long term.]
CIC will be looking for sponsorship
Soon, the CIC will be announcing a project to research VPI standard and will be talking with large companies to fund it.
This is separate from the Liberty specification. Liberty is the organizational vehicle for facilitating the creation of this specification.
Working with Liberty/NewOrg will allow access to resources, including personnel and wikis, etc.
SIG Charter draft has been sent to committee members.
Joe says it looks good. "I'll be joining Liberty to support this." I'm a bit concerned about IPR, but we'll work with that.
User-driven Search
Search maps are a form of VPI. They would be one of the datatypes.
- File format
- Interactive API (macros)
- Policy Standards (Data Rights Management)
Future Agenda Topics
- Discuss the distinctions between a Service Endpoint and a Service Manager.