...
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
- Etc.
Any of these could be condensed into a three letter acronym that would be unambiguous throughout the document.
Editor's Response:
“Federation” is a collective structure, set of rules and standards. The FO is the organization that manages and provides support services to the Federation. Text suggested in 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.
Editor's Response:
NSTIC is pretty high level. Our approach seems consistent with that document.
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.
Editor's Response:
What we have today is periodic audits. Is anything more “active” possible today?
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.
Editor's Response:
Text added - see line 136, 156 and 168. Typically most of these would be in the membership contract.
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
Editor's Response:
Most of this seems too detailed for the document at hand. The last bullet maybe ...
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.
Editor's Response:
A topic for long discussion. Non trivial and expensive to implement. What LOAs??
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?
Editor's Response:
Maybe someday but how many levels of oversight do we need right now??
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.
Editor's Response:
This would depend on being notified of such violations, and/or negative results during periodic audits...
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.
Editor's Response:
The federation governing body establishes the rules; the FO implements them...
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.
Editor's Response:
See suggested text
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.
Editor's Response:
The “federation” is a collective, not necessarily an organizational entity.
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.
Editor's Response:
Done (sort of)... see suggested text
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?
Editor's Response:
Done... would seem to apply more to high LOA CSPs
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.
Editor's Response:
See suggested text
15. P. 19, line 194 Spell out RP.
Is this relying party, resource provider, or some other entity?
Editor's Response:
See suggested text
16. P. 11, line 199 Again, ‘federation’ is used ambiguously. Please clarify.
Editor's Response:
I can’t find this reference...
17. P. 12, the term ‘registration authority’ in the definition for a CSP is not defined.
Editor's Response:
Added (also clarified some definitions)
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.
Editor's Response:
TBD...
19. Please add an acronym key at the end of the document.
Editor's Response:
TBD...
20. The guidelines read to us that we have to be assessed for Liberty Alliance Identity Assurance by a Liberty Alliance Identity Assurance Expert Group approved assessor, so that we can then be assessed by the Kantara Management Board for Kantara Compliance.
It's unlikely this federation will participate with so many hoops to jump through before we can even begin to be mapped to your assurance levels. Particularly when our members would only be willing to meet level 1 (bilateral arrangements would be used for higher levels).
Editor's Response:
TBD...
21. General comment: I think the paper uses 'federation participant' and 'federation member' interchangeably.
This may need looking at.
Editor's Response:
I believe this was addressed in a previous round of edits.
22. Line 85: would suggest this be downgraded to 'may'.
Not all federation operators are in the business of providing credentials - this is often specifically the role of its members / participants.
Editor's Response:
This reference is for identiying credentials for the member IdP itself or it’s administrative contacts. I’ll clarify.
23. Line 132: not all federations will guarantee verification of 'identity', but will assure verification of assertion.
See section 6 of the UK federation Rules Of Membership for more detail.
Editor's Response:
Fair enough, although I think many readers will be confused by the difference...
24. Line 185: again, not all federations require this type of audit as a 'must' but as a reserve the right to audit.
Clarity needed here as to whether self-audit is included in the meaning of this sentence.
Editor's Response:
I’ve added clarifying text.
25. My main point is that the FO should be positioned more as kind of a notary, and the obligations for certification, policy mapping should be moved to accredited auditors and members.
Editor's Response:
I don’t agree. The Federation serves as a trust anchor and therefore must perform whatever obligations that entails. It may assign certain functions to the FO or it could adopt other means. Note that section 2 defines the FO roles as “may include...”
26. In general I would like to see that the document refers to the central KI glossary instead of a local one.
Editor's Response:
Is there one??
27. Line 83: Ignorant of the status of MDX standardization, and assuming that several options might exist: This is only one of several options.
E.g. in consideration of the EU TSL (trust service status list), the list of accredited root CAs is already given. The FO needs only to list the federation members and their roles using x.509 subject names. That list needs to be signed of course.An other alternative would be to provide signed meta data containing all member’s certificates This sentence could be changed like: “providing the trust anchor that allows reliable authentication and authorization of federation” members”
Editor's Response:
I believe the comments above apply mostly to PKI-based federations. I’ll try to clarify and point out alternatives.
28. Line 84: The FO should only specify the standards for certification, and how auditors and test facilities are accredited.
The pattern should follow ISO 9000/27000.
Editor's Response:
A role of the FO is to ensure that certification happens, not necessarily to perform certification.
29. Line 85: In my view the FO only vouches and publishes for the member, but the collection and maintenance of meta data (except the member’s subject names and roles) is up to each CSP or RP.
Editor's Response:
There are several different ways to accomplish this, including dynamic discovery and bilateral exchange. Clearly the member must create its own metadata (whch might be checked by the FO for sanity). However, the FO itself also creates some metadata WRT the member so that must be integrated somehow.
30. Line 87: The term trust anchor should only be used on one level, either technical (like a list of certificates) or social/legal.
I would rather prefer a usage on the technical level. There is no definition in this document or in the glossary.
Editor's Response:
I’ll try to clarify. My intention was to offer a parallel to the PKI TA as a way to help readers understand the role of the FO.
31. Line 115: “Members .. are eligible for membership” – the category member is too general and should be deleted.
Editor's Response:
What entities are eligible for membership is an issue, e.g. must be a legal entity perhaps. I’ll try to clarify.
32. Line 116: Ony CSP is defined in the KI glossary, and IdP is synonymous.
Editor's Response:
IdP is also in the glossary. Some federations use one term and others use the other term. They may or may not be fully synonymous so I didn’t want to assume that.
33. Line 166: (syntax) information of and respect for
Editor's Response:
Thanks - I’ll fix that.
34. Line 170: In my view the FO role is more like to that of a notary.
The participant would be responsible to do the mapping and have the compliance certified by an auditor accredited for the Federation. The FO may aid the process as a service, but is only responsible to publish the results.
Editor's Response:
Like many dutues, this could be delegated. The FO must ensure it happens and is in accord with federation standards.
35. Line 200: The Document should use the Kanrata Glossary instead of this one.
Definitions are different. IdP and CSP have different definitions, although seem to have a similar concept.
Editor's Response:
Agreed, but that is not yet available.
36. Definition Table - “Cross Certify”: Terms that are not used in the document should not be defined here
Editor's Response:
I agree that the Glossary needs a lot of work. TBD.
37. Line 201: These references are not being referenced in the document.
They should be renamed to “Further reading” or inserted at the proper places in the document or removed if not required.
Editor's Response:
Agreed.
38. IdP vs. CSP
Line #74 prefers IdP, but CSP is still being used in some parts of the document.
Editor's Response:
???
39. Scope of the federation (and FO duties):
Line #78 says: "An identity federation is a set of identity service providers and relying parties [..] that agree to operate under compatible policies, standards, and in order that end-user identity information provided by IdPs can be understood and trusted by RPs."
Was it a conscious decision to limit the function if the federation to entity authentication assurance? An identity federation is subset of a trust federation, although the major one. Other objectives in a trust federation might be:
1. Confidentiality requirements by the RP to the user
2. User requirements to RP:
2a. Privacy beyond idm-specifc PII (like OIX's Levels of Protection)
2b. Information security (like protection against malware on server and correct processing of IdP assertions and meta data)
3. Service level (Availability, liability) of the IdP from the RP's perspective
4. According the the definition of IdP, attribute providers are not included
5. Service level of the RP to the user
The role definition of the FO is not quite clear:
Line #111 says: "In this document, the term Federation refers to the [entities] that together define, create and support the trust framework upon which federation members rely."
Although a trust framework is mentioned, only identity federation activities are mentioned.
I would see some arguments for making the complete set of requirements of a trust federation a concern of the FO:
a) If the scope of the federation is too limited, additional bilateral contracts would be needed, reducing the effectiveness of the contractual framework.
b) To make inter-federation contracts manageable, a single trust framework would be needed.
c) Given that the other areas must be managed somehow, it seems incomplete to me, if a FO would not be charged with the management the these areas, at least number 1 to 5.
Editor's Response:
???
40. line #276: "and assurance level are critical to proper" - levels should be plural.
Editor's Response:
???
41. page 8: some acronym definitions are not used, or will not be used if the glossary is moved to a glossary document:
FBCA, HSPD, IDABC, NIH, PEGS, and my be others.
Editor's Response:
???