Skip to end of metadata
Go to start of metadata

This page serves as a working space for the Privacy Assessment Criteria (PAC).

Here you will find working drafts, documentation and comments.

PAC Document Development References

  1. Current PAC document draft
  2. ICAM-FICAM Privacy Guidance for Trust Framework Assessors and Auditors (June 2011)
  3. Kantara Additional Requirements for Credential Service Providers: US Federal Privacy Criteria (Feb 2012
  • No labels


  1. I haven't finished my comments and in any event, I doubt they will come up to the same quality as those offered so far.

    But I see a trend running through Bob's questions and the answers that I should bring up now..

    An example: About half way through the doc, Bob qualified his comments with law enforcement issues (see 1.5, drafters note 2... 'fraud detection and subpoenas must be accomodated..' 

    If we start mixing legitimate law enforcement, legal interceptione etc with run-of-the-mill citizen access to government services(at least in the normative part) , I think we are really going to confuse folks.

    It seems like we are missing an introduction which sets FICAM's context, and its over-arching use case with some over arching principles/assumptions we agree on...

    Let's indicate an over arching use case as a citizen logging on, and go as far as indicating a typical message flow for this. Why? Because from the comments from Jeff and David, they have a different  view of the message flow, and who is doing what to whom and when.

    Another example: privacy aspects of 'identification' (is this identiity proofing that some EU states call 'initial authentication?) vs authentication (where the identity is confirmed by way of the electronic credential bound to the identity being presented to the IdP and subsequently asserted to the RP.... There we go again. More assumptions about the actors, and their roles (is the actor doing the identity proofing the same actor who knows the electronic credential and 'authenticating' the user with the logon process, before passing the user back to the RP to continue the transaction?. Where does the scope of FICAM begin and end? I don't recall it extending to identity proofing (I would be wrong). so let's not go there (at least for the normative part of the doc)

    Another example: Applicability of the Privacy Act:If I understand the scope of FICAM correctly it is not just a federation of federal agencies. It covers State as well (please correct me if I'm wrong). So let's be explicit up front in the introduction. The use case covers joint state/federal federations, so the Privacy Act will not always be applicable (but as far as possible reflective of it).

    So what do you think? Will we clear up many of these questions by matching the docs scope directly with FICAM, make that explicit in some introduction text, and only then delve into the criteria?



  2. user-4623d

    (Comments added on behalf of Kenneth Dagg)

    I apologize for entering the discussion of the PAC only at this late date. I have been subsumed by day-job priorities associated with standing up commercial CSPs for the GC.

    For the most part I am in agreement with what Colin has proposed. I would also say that it is a significant, and very important, step forward in this area.

    I have two main concerns however.  The first deals with the ultimate goal.  The second deals with the focus of the 1st release of the PAC.  My concerns are based upon the words that appear Colin's document rather than the discussions (which I have not been a part of) that may have occurred.  If my comments are inline with the discussions then I apologize for having missed them.

    Ultimate goal:  The ultimate goal of the PAC is currently stated as, "to provide an 'assessment baseline' for those charged with assessing or auditing the implementation of Privacy Policy by CSPs/IdPs and others engaged in federated identity and subsequent transactions online." My concern is that this goal is too narrow and, I would suggest, restrictive.  I would suggest that it should be more broadly stated as, "to provide assessment criteria for assessing or auditing the implementation of Privacy by CSPs/IdPs."  I would suggest that they be required criteria rather than a baseline (though this might be what was meant).  Federations can decide to have their own profile of the required criteria. I would suggest that using the term "privacy policy" might provide some federations with the idea that they can "not do something" because they do not have or subscribe to a privacy policy. I would suggest dropping the last part of the original and developing a set of RP (relying or receiving party) criteria related to privacy.

    Focus of 1st release.  I would suggest that specifying an initial focus of the US will potentially cause too restrictive a set of criteria which might be difficult to expand.  I would suggest that New Zealand and Canada (and possibly other jurisdictions or communities) have privacy requirements that could be built upon to develop the initial version of the PAC. It would then be incumbent of the US to develop their profile of this generic PAC for their own use.  If this is not a possible scenario then it should be explicitly stated from the outset that the initial version of the PAC is the US profile of a more generic (and still to be developed) PAC. Given this statement, I would further suggest that the sections of the proposed document be reorder to reflect the general and then the specific.  I would suggest that this understanding of scope is important in order to ensure that the PAC is viewed as having world-wide relevance rather than just US Government relevance. In my opinion, privacy has too high an importance to be only perceived as a US issue.


  3. Comments posted To P3 By David Wasley

    The PAC for CSP/IDPs -should-, nay, -must- address the release of any and all information about the identity Subject.  What is needed for access management is included as well as what is not needed for that purpose.  Different RPs will require and/or ask for different things based on what is needed for access and/or enhanced services or maybe just to see what they can get.  For example, some RPs may require merely an assertion that the Subject is more than 18 years old.  Others might require a unique identifier and would like a "common name" in order to personalize communications.  Etc. etc.

    FWIW, the above is consistent with what US federal ICAM requires be addressed.

    Ultimately both CSP/IDPs and SP/RPs will need to adhere to some set of privacy constraints.  NSTIC will certainly require it.  The EU already does require it.

    If, as you say, the PAC "addresses only the privacy protection by the CSP/IDP of the minimum amount of data required for authentication.  It does not address in any way the maintenance of privacy of attributes.  Nor does it address the potential privacy issues of the authentication data as it may be used in other aspects of an online transaction by other parties to the transaction" then in my opinion it is a waste of time.


  4. Comments Posted: By Jeff Stollman

    One thing that I think needs to be more specifically highlighted is the the PAC addresses only the privacy protection by the CSP/IDP of the minimum amount of data required for authentication.  It does not address in any way the maintenance of privacy of attributes.  Nor does it address the potential privacy issues of the authentication data as it may be used in other aspects of an online transaction by other parties to the transaction.


  5. From Joni/Susan

    I wanted to touch briefly here on the approach that I believe P3 reached consensus for on today's call.  The concept entails a kind of phased approach regarding specific Privacy Criteria for compliance.  Phase 1 capture what we (collective we) know needs to be fulfilled in terms of compliance (this is set by governments, regulators etc).  That phase is the starting point.  Phase 2 starts to approach the stretch goals and predictions.  

    For example: 
    We know X must be done to satisfy regulations today.  Additionally, we predict (based on research and discussion with stakeholders) that Y will become a regulation / best practice in the future.  So orgs would do well to do X and Y if they can today.  But today only X is required.  

    What this approach does is allow for current practices and technologies to comply with the regulations of today... but it starts to position the next steps as to the direction we believe privacy regulation and best practices will push toward in the future.  This approach is meant NOT to create barriers - but a hard line on what's needed RIGHT NOW for compliance ---- and then starts to drive the discussions and developments toward the future regulations and constraints a particular jurisdiction or vertical might have.