New draft of PFIF 1.3 specification, dated February 10

[Ka-Ping Yee]

Hello everyone,

Thank you for your continued feedback on PFIF.  A new draft of the PFIF 1.3 specification is now available here:

    http://zesty.ca/pfif/1.3

Please reply to the public PFIF list, pf...@googlegroups.com, with your thoughts and concerns.  If you see no concerns with it, that feedback is useful too.  (Note that this message is being copied to a few other lists, so be sure to address your feedback to pf...@googlegroups.com.)

The major change in this draft is that it explicitly permits the original repository to change an existing record.  This is necessary so that the original repository can make corrections to incorrect data, and also so it can expire or delete an existing record.

My target date for freezing PFIF 1.3 is one week from today.  If you have any comments, please send them in before 17:00 PST, Wednesday February 16.

Thank you!

—Ping
Google Crisis Response

[Tim Schwartz]

Sorry for the mass email, I thought it was important to copy in the
relevant text from the PFIF 1.3 Draft dealing with expiry date and
bring up a few points.

-Can the expiry date be modified?

-Is the expiry date explicitly owned by the owner, ie can anyone else
change the expiry date?

-Should there be a default expiry date if the owner doesn't assign one
upon creation?

-Can the expiry date be changed after a record has already past the
expiry date? ie Can i set the expiry date to tomorrow, and then
tomorrow change the expiry date to two weeks from now, or even the day
after tomorrow?

-Does the host provide the expiry date based on the conflict/disaster
circumstances or does the individual giving their data provide the
expiry date?

Here is the relevant text from http://zesty.ca/pfif/1.3/#data-expiry:

3.3. Data expiry mechanism

If present, the expiry_date field indicates when a record should be
deleted to preserve the privacy of the personal information it
contains. Conforming PFIF implementations must meet the following
requirements:

-Within one day after expiry_date, a PFIF repository must make the
contents of the PERSON record and any associated NOTE records
inaccessible to all external clients, including users and machine API
clients.

-Thereafter, if the repository exports its data through an API, it
should continue to export a placeholder record in the place of the
expired PERSON record. This placeholder should have the same record
identifier, keep the same expiry_date value, and have both source_date
and entry_date set to the time that the placeholder was created. All
other fields of the placeholder record should be present and empty.

-Within 60 days after expiry_date, a PFIF repository must permanently
and unrecoverably delete all local copies of the data in the PERSON
record and any associated NOTE records.

A PFIF repository can delete an existing original record by updating
the record and setting its expiry_date, source_date, and entry_date to
the current time. The expiry mechanism described above would then
cause this deletion to propagate to other conforming PFIF
repositories.

On Thu, Feb 10, 2011 at 5:36 PM, CrisisCommons <crisis...@gmail.com> wrote:
>
>
> Begin forwarded message:

[Jim Cory]

Thank you Ping for your work on this. I know that this is about the information and not policy, but at some point in the process, policy will influence which records are sensitive and must be protected. Perhaps we need to model this in the database initially to provide consistency. One possibility would be to add a "Protected" field with a simple "true/false" value. Reasons for the setting could be put in the free form text field.

Jim Cory

Horizon Mapping

http://www.horizonmapping.net

jco...@charter.net

On Thu, Feb 10, 2011 at 7:05 PM, Ka-Ping Yee wrote:

 Hello everyone,

Thank you for your continued feedback on PFIF.  A new draft of the PFIF 1.3 specification is now available here:

     http://zesty.ca/pfif/1.3

Please reply to the public PFIF list, pf...@googlegroups.com, with your thoughts and concerns.  If you see no concerns with it, that feedback is useful too.  (Note that this message is being copied to a few other lists, so be sure to address your feedback to  pf...@googlegroups.com.)

The major change in this draft is that it  explicitly permits the original repository to change an existing record .  This is necessary so that the original repository can make corrections to incorrect data, and also so it can expire or delete an existing record.

[Chamindra de Silva]

I tent to agree with Jim. In the old version of Sahana at least we tried to incoorporate different data sensitivity classifications http://wiki.sahanafoundation.org/phase2/doku.php/dev:security and our security access mechanisms were based on these classifications. However in hindsight we probably implemented too many classifications, when something a little simpler would have been sufficient to propagate the level of sensitivity of that record. Govs and large NGOs have legal constraints and have to be accountable to the data they share. There are abuses that can result with things like identify theft we found in certain instances post disaster and abuses in areas of conflict, however more often than not data sharing is far better than not.

Also to Tim's point on enforcing a contract on expiry would be most welcome in the spec and it would be a good interop test to certify systems that fully implement that contract. For the same reasons as above the source organization has to have the ability to remove or change replicas of their data on the web.


Chamindra de Silva
http://chamindra-de-silva.blogspot.com | http://twitter.com/ChamindraS

[Ka-Ping Yee]

Hi Tim,

Thanks for the good questions!  I'm grateful for the close review.

-Can the expiry date be modified?

Yes.  The original repository (but no other repository) can change the expiry_date field, like other fields.

 

-Is the expiry date explicitly owned by the owner, ie can anyone else
change the expiry date?

The expiry_date is owned by the original repository, again like other fields.  Other repositories should not change it.

-Should there be a default expiry date if the owner doesn't assign one
upon creation?

This is up to the repository where the original record is created.  I would tend to agree that this is a good practice for most repositories.

-Can the expiry date be changed after a record has already past the
expiry date? ie Can i set the expiry date to tomorrow, and then
tomorrow change the expiry date to two weeks from now, or even the day
after tomorrow?

This is also up to the original repository.  When the expiry date passes, the record should disappear from external view.  However, the spec allows a grace period of 60 days after that for the original repository to delete all of its backups; and repositories can use this grace period to implement recovery from a mistaken deletion.  You can think of resetting the expiry date of an expired record into the future as equivalent to re-creating the same record from a backup (and, to API clients, it should appear just this way).

-Does the host provide the expiry date based on the conflict/disaster
circumstances or does the individual giving their data provide the
expiry date?

The original repository can choose how it wants to present this decision to its users.

Hope that all makes sense?

—Ping

Google Crisis Response

[Ka-Ping Yee]

Hi,

I've responded to Tim's questions on the PFIF list; please see http://googlegroups.com/group/pfif .

—Ping
Google Crisis Response

[Ka-Ping Yee]

Hello Chamindra,

Thanks for the feedback.

On Fri, Feb 11, 2011 at 10:10, Chamindra de Silva <cham...@opensource.lk> wrote:

I tent to agree with Jim. In the old version of Sahana at least we tried to incoorporate different data sensitivity classifications http://wiki.sahanafoundation.org/phase2/doku.php/dev:security and our security access mechanisms were based on these classifications. However in hindsight we probably implemented too many classifications, when something a little simpler would have been sufficient to propagate the level of sensitivity of that record.

 

On the issue of sensitivity classifications, I think they would only be useful if we had agreed-upon, actionable meanings for the classifications.  I'm open to discussing this for a future version of PFIF but would rather not hold back PFIF 1.3.

Also to Tim's point on enforcing a contract on expiry would be most welcome in the spec and it would be a good interop test to certify systems that fully implement that contract. For the same reasons as above the source organization has to have the ability to remove or change replicas of their data on the web.

I agree that this makes a good interoperability test.  In the new draft, section 3.3 (Data expiry mechanism) specifies a set of requirements that PFIF repositories must fulfill for handling deleted/expired data; do you see any problems with it?

—Ping
Google Crisis Response

[Tim Schwartz]

Thanks for the clarifications Ping!
-tim

On Feb 11, 5:59 pm, Ka-Ping Yee <k...@google.com> wrote:
> Hi,
>
> I've responded to Tim's questions on the PFIF list; please seehttp://googlegroups.com/group/pfif.
>
> —Ping
> Google Crisis Response
>

[Chamindra de Silva]

Hi Ka-Ping

On Sat, Feb 12, 2011 at 7:34 AM, Ka-Ping Yee <k...@google.com> wrote:

Hello Chamindra,

Thanks for the feedback.

On Fri, Feb 11, 2011 at 10:10, Chamindra de Silva <cham...@opensource.lk> wrote:

I tent to agree with Jim. In the old version of Sahana at least we tried to incoorporate different data sensitivity classifications http://wiki.sahanafoundation.org/phase2/doku.php/dev:security and our security access mechanisms were based on these classifications. However in hindsight we probably implemented too many classifications, when something a little simpler would have been sufficient to propagate the level of sensitivity of that record.

 

On the issue of sensitivity classifications, I think they would only be useful if we had agreed-upon, actionable meanings for the classifications.  I'm open to discussing this for a future version of PFIF but would rather not hold back PFIF 1.3.

Agreed. Certainly, let's not hold back 1.3 for this one. Great work so far. There needs to be further discussion and a consensus on sensitivity/confidentiality classifications for it to actually be useful, so let's leave that for a later version of PFIF.

Also to Tim's point on enforcing a contract on expiry would be most welcome in the spec and it would be a good interop test to certify systems that fully implement that contract. For the same reasons as above the source organization has to have the ability to remove or change replicas of their data on the web.

I agree that this makes a good interoperability test.  In the new draft, section 3.3 (Data expiry mechanism) specifies a set of requirements that PFIF repositories must fulfill for handling deleted/expired data; do you see any problems with it?

3.3 looks good. The challenge will be to verify that systems actually implement it, especially the 60 day expiry. With interop testing we can report the degree to which the various products implement the specification and report for example when sections like 3.3 (data protection controls) are not properly implemented. IMO This will be an incentive to drive complete coverage of the spec amongst products. We can start drafting some use-cases / abuse-cases and associated test cases on this spec when you are ready based on common missing person data interop scenarios. I would be happy to help draft something on that.