[WG-P3] [SG-P3PF] Fwd: P3WG's PAC - Addressing a different class of service providers.

Wed Sep 28 21:34:26 EDT 2011

Well it sort of depends on what you want covered. (engeneers answer)

The TFAP only applies to CSP that are acting as external agents.

The PAC could be applied to the other sort but that would be voluntary unless the GSA mandates it in some other way(I don't know that they have the authority)

It is the Cloud Service providers like IdeaScale acting as RP on behalf of federal agencies that need some sort of PAC to say they meet The federal requirements for agencies.

Currently there are no requirements on them ether for privacy or for the sorts of credentials they accept.  

As an example you can go to the DHS site https://openhomelandsecurity.ideascale.com/.

This is outsourced by DHS to a SAS provider IdeaScale to take comments about homeland security.  IdeaScale outsources's authentication to a SAS vendor JainRain's Engage product.  JainRain then relays on IdP such as Facebook to authenticate users.

Not one part of the outsourcing chain is certified in any way.   The GSA seems to have little control over this.

I think that Judy is trying to cover this contingency by saying that just because DHS is using a SAS vender they don't get to ignore FICAM, the FICAM requirements are passed on down the chain.

Now as far as privacy goes there are FICAM RP requirements, so even if IdeaScale were somehow covered by FICAM that probably only applies to their choice of IdP and security.

If there were a PAC for RP like IdaScale/JainRain then the GSA might be able to require that as well.   
I don't think the PAC is intended to apply to RP so that is probably out of scope.

Though I have said many times that PAC and certification of RP would be a good thing.

John
On 2011-09-28, at 9:06 PM, Colin Wallis wrote:

> <<JB: If the CSP is a direct contractor to an agency,  it is unclear that the TFAP applies certainly there are lots of existing contracts of that sort currently.  I think those relationships are out of scope for the TFAP.>>
>  
> CW: So…. Where does that leave us with the text? I think you have just landed yourself a re-hash job along with Dave – how much or how little re-hash is still not certain it seems..
>  
>  
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Thursday, 29 September 2011 12:54 p.m.
> To: Colin Wallis
> Cc: 'David L. Wasley'; Mark Lizar; Kantara P3WG
> Subject: Re: [WG-P3] [SG-P3PF] Fwd: P3WG's PAC - Addressing a different class of service providers.
>  
> I think what they are trying to get at is not that TFP or CSP are direct federal contractors and subject to federal regulation,  though some laws like access for people with disabilities may wind up getting extended to CSP when they are providing access to Federal agencies.
>  
> What they are trying to cover are fedramp  cloud services and other direct contractors to Federal agencies who are covered under federal regulation just as a federal agency is when dealing with CSP.
>  
> In some cases agencies have circumvented regulation by having a 3rd party provide the hosting (I know of a couple of examples).
>  
> If the CSP is a direct contractor to an agency,  it is unclear that the TFAP applies certainly there are lots of existing contracts of that sort currently.  
> I think those relationships are out of scope for the TFAP.
>  
> John
>  
>  
> On 2011-09-28, at 8:39 PM, Colin Wallis wrote:
> 
> 
> Great response David
>  
> We are getting closer to the nub of it.
>  
> Let’s discuss and finalise on the call, and then ask you to correct the text. I think you have the closest handle on the facts.
>  
> But I’ll briefly comment inline below.
>  
> Cheers
> Colin  
>  
> From: David L. Wasley [mailto:dlwasley at earthlink.net] 
> Sent: Thursday, 29 September 2011 11:31 a.m.
> To: Colin Wallis
> Cc: Mark Lizar; Kantara P3WG
> Subject: Re: [SG-P3PF] Fwd: P3WG's PAC - Addressing a different class of service providers.
>  
> Colin,  I think the text you sent makes it even more confusing (to me anyway).  I can't tell whether it is saying that a TFP is de facto subject to Federal executive branch regulations or not.  
> <<CW: It was saying it was because that is what the text in the TFPAP and Privacy Guidelines led me to believe>>.
>  
> I believe the actual case is that TFPs are -not- subject to such regulations, e.g., NIST 800-53, because that is what Deb Gallagher told me in an email.  However I could read your text to imply that TFPs -are- so subject, even if only by subtle implication.
> <<CW: So let’s go with Deb Gallagher’s interpretation of what the TFPAP and the Privacy guidelines reference to it says. It will be better than mine! J >>
>  
> What FICAM/TFET is requiring of TFPs is purely up to them.  They have chosen to require something similar to that which is required of Federal agencies.  The only relevant source for what they are in fact requiring of TFPs is to be found in their TFPAP document. The fact that TFP CSPs will interact with Federal agency applications does not make the TFP CSP a "Federal Information System" for example.  FICAM does not consider it the case that Federal agencies are "outsourcing" identity management to non-federal CSPs.
> <<CW: OK, let’s make that explicit, because my feeling is there are maybe only a handful of people in the world who have got that interpretation>>
>  
> That said then, what is the relationship between the IAWG "Identity Assurance Framework: US Federal Privacy Profile"  and the P3WG "Privacy Assessment Criteria" document?  
> <<CW: A question of much debate for months and months in P3WG..I’ll let those much closer to it, offer a comment here,.  From afar, I saw it simply as… ‘the TFPAP requires privacy to be considered but offers scant detail, the Privacy Profile does that, the IAWG’s IAF does not explicitly call out privacy to the extent that an assessor could see that a CSP deploying the IAF has in fact complied with the privacy profile in order to be a certified as per the TFP. The PAC will help CSPs deploy the IAF in a way that will ease their FICAM  TFP challenge>>.
>  
> For example, I could see a case for a set of criteria that -would- apply to a TFP CSP that had a contract for identity management as an outsourced activity of a Federal agency.  In that case, NIST 800-53 would indeed apply.  Etc.
> <<CW: Agreed. Given what you have said, maybe this is the only use case we are answering..>>
>  
> Does this help explain my confusion?
>  
>             David
>  
>  
> On Sep 28, 2011, at 2:36 PM, Colin Wallis wrote:
> 
> 
> 
> David
>  
> That question has been asked (but in a different way) last week, and it resulted in a decision to draft an Introduction section so that this issue amongst many others that were confusing, could be clarified, before a reader went into the detail of the document.
>  
> In case you have not seen this draft text here it is below.
>  
> Perhaps it would be best to suggest alternative language in this as well as the one sentence lead in that is in the PAC at present?
>  
> Cheers
> Colin
> ………………………………………………………………………………………………………………………………………
>  
> Introduction
>  
> On September 4th 2009, the US Government's FICAM (Federated Identity Credentialing and Access Management) program published the Trust Framework Provider Adoption Process (TFPAP) for Levels of Assurance 1,2 and non -PKI 3. 
> On June 29, 2011. FICAM published Version 1.0 of its Privacy Guidance for Trust Framework Assessors and Auditors.  Readers are strongly encouraged to thoroughly familiarise themselves with these publications.
>  
> As a Trust Framework Provider (TFP) in its own right, with its own Identity Assurance Framework and TFP assessor accreditation program, the Kantara Initiative has provisional certification as a FICAM TFP for its own Identity Assurance Framework. 
>  
> Kantara's Privacy and Public Policy Working Group has released this paper, the Privacy Assessment Criteria, to help CSPs/IDPs and RPs/SPs in trust frameworks seeking certification as a FICAM TFP, position themselves optimally with FICAM's June 2011 release of the Privacy Guidance for Trust Framework Assessors and Auditors.  
>  
> This Kantara Privacy Assessment Criteria helps address not only the baseline FICAM publications mentioned above, but also NIST SP 800-53 Appendix J 'Security and Privacy Controls for Federal Information Systems and Organizations' and reflects the privacy requirements of its own Identity Assurance Framework.  While the focus of this version of the Privacy Assessment Criteria is squarely focussed on US interests, it has been designed to be extensible for use in other jurisdictions globally. 
>  
> The scope of the work is directly reflective of the scope of the FICAM program itself, and although no specific statement of scope is set out in the FICAM publications mentioned above, several 'scope-like' passages (substantially quoted below) offer a reasonably clear intent: 
>  
> FICAM trust framework cover remote electronic authentication of human users to IT systems over a network - it does not address the authentication of a person who is physically present
> It serves the interest of US Government organizations as Relying Parties, and promotes interoperability between Federal and non Federal entities      
> CSPs/IDPs and RPs/SPs both have privacy protection responsibilities, although collaboration on privacy practices between RPs and IDPs is anticipated in order to provide a seamless experience for Users and meaningful and effective implementation of the TFPAP Criteria
> In some cases federal agencies may contract with external contractors or commercial third parties for certain functions. Such non-federal entities are considered agents of the federal government and therefore IDPs must interact with them as if they were interacting with a federal agency application.
>  
> The passages above serve to demonstrate that FICAM's scope (and therefore the Privacy Assessment Criteria scope) is limited to:
>  
> users of government online services logging onto and accessing those services, and does not extend to lawful interception
> confirmation (to a level of assurance) of the binding of the user's identity to a credential through the process of online authentication, and does not  extend to initial authentication, identification or other synonyms for identity proofing of the user prior to binding the credential to the identity
> No specific authentication architecture or design pattern is prescribed, so all use cases for user authentication - for example (1) either direct to the IDP or redirected from the RP to the IDP for authentication and redirected back to the RP, and (2) the use of anonymous, pseudonymous or veronymous identifiers - are applicable, though there are substantially different privacy implications with these alternatives
> federal and non-federal entities are involved, so that various state privacy law is also applicable in certain transactions, with the Privacy Act applicable to federal agencies  
>  
> The Privacy Assessment Criteria uses the US's Fair Information Practice Principles (FIPPs) as template on which to develop the criteria, to reflect FICAMs TFPAP Privacy Criteria dependency on this.  Assessment criteria are applied to each principle in turn, along with additional notes and guidance to cover a range of possible use cases, architectures and design patterns.  
> 
>  
> From: sg-p3pf-bounces at kantarainitiative.org [mailto:sg-p3pf-bounces at kantarainitiative.org] On Behalf Of Mark Lizar
> Sent: Thursday, 29 September 2011 12:02 a.m.
> To: Kantara P3WG
> Cc: Privacy Framework; David L. Wasley
> Subject: [SG-P3PF] Fwd: P3WG's PAC - Addressing a different class of service providers.
> Importance: High
>  
> Thanks David,
>  
> Excellent points to raise which need to be discussed and addressed.   I will add these to the Agenda for the call this Thursday.  
>  
> Thank you, 
>  
> - Mark
>  
> Is it possible for  you to attend the call this Thursday (tomorrow) to discuss further? 
>  
>  
>  
> On 19Sep2011, at 9:05 PM, David L. Wasley wrote:
>  
> 
> Anna,  I started going thru this document and then realized that there is a fundamental dilemms:
>  
> The document states
>  
> These criteria apply to Credential Service Providers (CSP) providing US Federal Agency applications under the Open Government program.
>  
> This might be confusing since it could be interpreted as applying to CSPs that are certified to offer identity assertions -to- federal agency applications.  In fact, it would apply only to CSPs (or any non-federal entity) that is providing an out-sourced application that would otherwise be supported and run by the agency itself.
>  
> Deb Gallagher, chair of FICAM, pointed out this distinction to me.  It is important, and is why the IAWG has the Federal Privacy Profile.  The document you asked us to review is not duplicative of the IAWG document; it addresses a different class of service providers.
>  
> Am I mis-reading the document?  If not, I'll suggest alternative language for the above extract.
>  
>             David
>  
> On Sep 19, 2011, at 10:03 AM, Anna Ticktin wrote:
>  
> 
> Hello Richard and David—
> 
> I have been asked by Joni and Anna Slomovic (P3WG chair) to forward this draft Privacy Assessment Criteria doc (PAC) to the both of you (as previous editors for the iAF) for feedback and advisement—specifically: definitional questions/issues (which I believe have been highlighted in yellow on the draft doc.).
> 
> I know this tract will be driven by the P3WG on its regular calls whilst partnering with the IAWG for some of their agenda time and support.
> 
> Thoughts?
> 
> Regards.
> —> Anna Ticktin
> 
>       Technical Program Coordinator
>       anna at kantarainitiative.org
>       anna at ieee-isto.org
> 
> 
> <RG-Kantara-1-4.doc>
>  
>  
>  
> ====
> CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.
> ====
>  
> ====
> CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.
> ==== _______________________________________________
> WG-P3 mailing list
> WG-P3 at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-p3
>  
> ====
> CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.
> ====

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-p3/attachments/20110928/82e80797/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-p3/attachments/20110928/82e80797/attachment-0001.bin 