OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Privacy


Title: メッセージ

Nat,

 

It's a great question. The XRI TC has the requirement to ensure that the XRI syntax does not REQUIRE identifiers that will reveal personally-identifable data. But this requirement is not hard to fulfill. For example, the use of a completely non-semantic identifier (for example, a UUID) would not require the use of any personally-identifiable data.

 

But your use case, where a human-readable identifier that contains personally-identifiable data (such as a person's real-world name) is coupled with a permanent identifier, is indeed a data structure that would fall under the EU Directive and Japanese Privacy act. And I'm sure there are many other examples of how human-readable semantic identifiers could be used to reveal personally-identifiable data. The question is whether mechanisms for controlling the privacy or security of such data should be in the scope of the XRI TC.

 

My own point-of-view (and it's just one) is that we should limit the scope of the XRI TC to defining syntax and a basic resolution mechanism that may not fully address secure resolution or privacy-protected resolution because, as you say, those issues may not be solvable without specifying XRI data interchange mechanisms. And we agreed at the f2f that this would be the focus of the follow-on TC.

 

So it's looking like that TC will need to form sooner rather than later. I've had this conversation with several other TC members who feel the same way, so we'll need to start looking at creating the charter pretty shortly.

 

Best,

 

=Drummond

 

-----Original Message-----
From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
Sent: Wednesday, March 26, 2003 4:45 PM
To: xri@lists.oasis-open.org
Subject: [xri] Privacy

 

Allow me to think loud in this mailing list.

It is a privacy issue which should/should not be involved in XRI requirements.

 

At the F2F meeting I was convinced that given appropriate plug-in architecture for the security provision, this issue could be largely deferred to the follow on TCs. I am not so sure now.

 

Let me first define "Privacy data". According to EU directive and Japanese Privacy act (both are derived from OECD privacy principles so are very similar), it is "Any data stored in relation to a personally identifiable data." An example of personally identifiable data is the combination of a person's last and first name in a certain context.

 

XRI requirement for the Human readability probably implies that there will be a XRI reassign able identifier that is very similar to a person's real name. Then, any bits resolved using this human readable identifier and thus stored with this identifier (e.g., permanent identifier stored with human readable identifier) is likely to be categorized as "Privacy data".

 

Once it becomes a "Privacy data", it needs to fulfill bunch of requirements from the EU directive etc. XRI probably needs to be able to cater such requirements.

 

Some of the prime example of such requirements are:

 

- Any collection of privacy data must be done with the pre-declared and agreed to purpose statement.

- A person  can decline the request for the data.

- A person can ask the other party to disclose what data the party holds about the person.

- A person can ask the party to remove any specific data about him, and the party must comply with it.

- Audit traceability is required and access log to the privacy data must be kept to ensure that any illegal data usage can be tracked.

 

These seem to require couple of things to XRI (and follow ons):

 

- Rudimentary contract framework : Required for the pre-declaratin of the purpose statement and the consent to it.

- Access control based on the contract

- Data removal request message format

- Standard access/audit log for the resolution.

 

My question is: "Is it really possible to push all these to follow-on TCs without taking at least some consideration in the basic addressing and resolution framework that current TC is trying to tackle?"

 

Your input is much appreciated.

 

Regards,

 

--

Nat Sakimura, Nomura Research Institute.
xns name: =sakimura email: n-sakimura@nri.co.jp
http://www.marimba.org/~sakimura/blog/

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]