Meeting notes from November 24, 2014

From IDESG Wiki
Jump to navigation Jump to search

11/24/14 Privacy Requirements Working Group Meeting Notes

Attendees

  • Jenn Behrens
  • Doug Blough
  • Jeff Brennan
  • Sean Brooks
  • David Bruggeman
  • Jessica Esparza
  • Edmund Jay
  • Ken Klingenstein
  • Naomi Lefkovitz
  • Ellen Nadeau
  • Ann Racuya-Robbins
  • Stuart Shapiro
  • Jim Zok

Meeting Notes

  • Indicate attributes will always mean attribute values
    • Discussed release issues: how do you do release of multi-value attributes?

Functional Requirements Edits

  • Requirement: “Identifiers shall be segregated from attributes whenever feasible.”
    • Registration: Attributes should be provided as claims as often as possible.
    • Committee discussed further explaining “identifiers” but decided it’s commonly used terminology so explanation not necessary.
    • You mitigate privacy risks if you keep info that could be used to identify someone separate from attributes or whatever transaction is involved. Usually this means keeping the info in distinct databases, but could be different tables in same database – depends on risk assessment.
      • Ann will put minority opinion for line 21 in requirements on the wiki.
  • Requirement: “Organizations shall, upon any material changes to a service that affect the prior or ongoing collection, use, dissemination, or maintenance of users’ personal information: a) provide clear and conspicuous descriptions of the changes and their impacts on users in advance, and b) with respect to previously collected personal information, provide users with compensating controls designed to mitigate privacy risks that may arise from the material changes, which may include seeking express affirmative consent of users in accordance with relevant law or regulation. In the event that users elect to terminate the service, organizations shall meet other stated requirements on termination and retention.”
    • Registration: ✔

Completed registration column. Reviewed functional model:

  • Credentialing:
    • Credential provisioning
    • Token binding
    • Attribute binding
    • Revocation
  • Requirement: “Organizations shall limit the collection and transmission of information to the minimum necessary to fulfill the transaction’s purpose and related legal requirements.”
    • Credentialing: Whenever possible bind credentials to claims instead of actual attribute values.
    • Authentication: Leave the attribute home whenever possible. Just need to know someone’s over 21 – don’t need to know their birthdate.
    • When you’re creating a credential, you don’t know which claims you need, thus which claims to bind.
    • Potential definition of claim: a derived assertion, derived from a set of values, and the derivation is intended to answer a specific question without revealing additional info.
    • Authentication:
      • Referring to collection & transmission. We’ve seen that RPs get buckets of info, then it makes them harder to request only what they need. They’re given a whole bucket, and users have to say yes to the whole bucket.
    • Attributes seem to be authorization, not authentication.
      • Release of attributes shouldn’t be result of authentication – this is a privacy issue.
        • If done correctly, you’re saying, here’s your credential, is it still valid? You say yes or no, I decide to accept it or not.
        • Attributes related to individual aren’t involved with authentication.
        • Take requesting out of the authentication wording?
        • Split re: organizations requesting info & those releasing info? Could be confusing if we have to go split box from here on out.


Requirements for Discussion Next Meeting

  • Requirement: “Organizations shall limit the collection and transmission of information to the minimum necessary to fulfill the transaction’s purpose and related legal requirements.””
    • Authentication:
      • Attributes should be transmitted as claims whenever possible.
      • Organizations providing claims or attributes should not provide any more information than what is requested, and should provide a sufficiently granular, technical mechanism for processing specific information.
  • Authorization:
    • For organizations requesting attributes: Evaluate the need to collect specific attributes in a transaction as opposed to claims from individuals regarding those attributes.
    • For organizations releasing attributes: Provide the opportunity for attributes to be released as claims as well as detailed attributes.
    • Organizations providing claims or attributes should not provide any more information than what is requested, and should provide a sufficiently granular, technical mechanism for requesting specific information.
  • Transaction Intermediation
    • For Intermediaries: Avoid collecting personal information whenever possible.
    • For Endpoints: Implement protocols that mitigate the risk of intermediaries collecting personal information.
  • Requirement: “Organizations shall limit the use of the individual’s data that is collected and transmitted to the specified purposes of the transaction.”
    • Credentialing: Contracts or assurances need to be established so that information, when passed between organizations, is still used in the same manner as originally specified.
    • Authentication: Contracts or assurances need to be established so that information, when passed between organizations, is still used in the same manner as originally specified.
    • Authorization: Contracts or assurances need to be established so that information, when passed between organizations, is still used in the same manner as originally specified.
    • Transaction Intermediation: Contracts or assurances need to be established so that information, when passed between organizations, is still used in the same manner as originally specified.

Actions

  • Group will work through above two requirements and drafted language.
  • Ann will develop minority report language