[KI-LC] Comments on IAWG Federation Operator Guidelines

Anna Ticktin annaticktin at me.com
Mon Jul 26 19:01:48 EDT 2010

This message is to inform the LC that the staff has received the following comments as one submission to the IAWG Federation Operator Guidelines document.  We expect the IAWG to review these comments on their next teleconference scheduled for Wednesday 28 July 2010.

Please note the comment period remains open until 16 September 2010. Further comments will be forward for your review and consideration upon receipt.

Selected Document: IAWG Federation Operator Guidelines

Comments: This is a series of comments relating to the draft Kantara document entitled Identity Assurnce Framework:  Federation Operator Guidelines.

1.  Introduction, p. 4  The name Federation Operator (FO) seems loaded with ambiguities.  The “identity federation” is something distinct from the Federation Operator.  An operator seems more like a process than a distinct entity.  There are many places in the document where the word ‘federation’ is used and it is not clear whether the term refers to the FO or the identity federation or something else.  I would suggest looking at other possible names to eliminate these ambiguities.  Possibilities might include:
	Identity system manager
	Identity federation manager
	Identity system coordinator
	Identity federation enabler
Any of these could be condensed into a three letter acronym that would be unambiguous throughout the document.
2.  Has Kantara gone through this document with an eye towards making sure it is compatible with the federal National Strategy for Trusted Identities in Cyberspace (NSTIC),www.nstic.ideascale.com?  It appears that NSTIC will establish the environment in which Federation Operators will need to function.
3.  P 4, line 83  I would add ‘overseeing enforcement’ as an additional function of an FO.  People will only trust an identity federation if they know there are mechanisms to detect and remove entities that do not play by the rules.
4.  P. 6, line 124  I would recommend adding an item that indicates the FO will include specific performance guarantees.  In order to build and maintain trust the FO will need to ensure interoperability across certain environments, the ability to maintain correct operation across version upgrades, compatibility with various standards, ability to support a set of identity functions, limitations on the time a given operation will require to become effective, etc.  These will need to be part of a list of specific performance guarantees offered by the FO.
5. P. 7, line 157  Consider adding additional bulleted items to the list.
•	Use cases demonstrating proper application of federation operator resources to solve real-world problems
•	Workflow diagrams illustrating proper sequencing of federation operator capabilities
•	An analysis of tools and methods available (required?) to detect fraud, error or misuse of identity federation capabilities
•	References to the laws and governance under which the FO operates
•	Policies and procedures for creating, suspending, restoring, revoking, upgrading or downgrading, and terminating a trusted identity
6.  In general I feel that the document does not deal at all adequately with the need for an FO to be able to detect and correct incidents, errors, fraud, malfeasance, etc.  In order to establish trust an FO will need to be able to ensure its potential customers that it knows how to keep its house in order.  Nothing will provide this assurance more powerfully than to demonstrate how the FO can strongly detect and rapidly & completely correct misdeeds in its identity environment.
7.  Should there be an independent 3rd party “FO tester” agency that acts like a ‘white hat hacker’ to test and verify the robustness of a FO’s ability to enforce proper identity management?
8.  The FO should have some sort of line in the sand concerning how rapidly it can a) detect and b) disable violations of proper identity management.
9.  P. 8, line 159  Is it the identity federation or the FO or both that should have membership process procedures in place?  This is an example of the ambiguity between identity federation and FO that seems to run through the entire document.
10.  P. 9, line 161  How does a Federated Network of Trust (FNT) relate to an FO?  How does it relate to an identity federation?  Why is FNT material contained in a document describing FOs? There should be an introductory section explaining this relationship and how this section relates to the FO topic.  
11.  P. 9, line 163  “… role of the federation …”  Another ambiguity, please clarify.  Is this a role of the FO or of the identity federation or both?  It might be extremely helpful if the document contained a diagram showing how FO(s), CSP(s) and identity federation(s), CSPs, IdPs, etc. relate.
12.  P. 9, line 165 “credential strength” is not defined.  I have an intuitive sense of what is meant here but I think this document needs to provide a precise definition.
13.  P. 9, line 180  I believe that the FO must agree to undergo active penetration and integrity testing by a 3rd party.  How else can a skeptic actually trust the FO’s claims?
14.  P. 9, line 184  I would change ‘annual’ to periodic.  I think it is likely that an FO will need to publish quarterly or even monthly compliance assessments.
15.  P. 19, line 194  Spell out RP.  Is this relying party, resource provider, or some other entity?
16.  P.  11, line 199  Again, ‘federation’ is used ambiguously.  Please clarify.
17.  P. 12, the term ‘registration authority’ in the definition for a CSP is not defined.
18.  P. 12 & 13  Any synonyms for a term being defined should be listed in that definition and given their own definition in the table.
19.  Please add an acronym key at the end of the document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/lc/attachments/20100726/e3eabf01/attachment.html 

More information about the LC mailing list