Source: https://kantarainitiative.org/confluence/pages/worddav/preview.action?fileName=KI+IAF-3410+v1.0_SAC_Profiling+Rules.doc&pageId=38371386
Timestamp: 2020-07-10 05:35:24
Document Index: 138613147

Matched Legal Cases: ['§ 2', '§3', '§ 2', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 3', '§ 2']

KI IAF-3410 v1.0_SAC_Profiling Rules.doc - WG - Identity Assurance OLD space - Kantara Initiative
WG - Identity Assurance OLD space
Minutas de Reunión
WG Approved Reports
IAF - US Federal Privacy Profile Report 1.0 - Contributors
US Federal Privacy-Additional Criteria for CSPs v2.0 Contributors
KI IAF-3410 v1.0_SAC_Profiling Rules.doc
Identity Assurance Framework:
Service Assessment Criteria –
Profiling Rules
Date : 2011-03-02
Editor : Richard G. Wilsher, Zygma LLC; Ben Wilson; and Myisha Frazier-McElveen
The full list of contributors can be referenced here:
http://kantarainitiative.org/confluence/x/CQS-Ag
The Kantara Initiative Identity Assurance Work Group (IAWG) was formed to foster adoption of identity trust services. The primary de liverable of the IAWG is the Identity Assurance Framework (IAF), which is comprised of many different documents that detail the levels of assurance and the certification program that bring the Framework to the marketplace. The IAF is comprised of a set of documents that includes an Overview publication, the IAF Glossary , a summary Assurance Levels document, and an Assurance Assessment Scheme (AAS), which encompasses the associated assessment and certification program, as well as several subordinate documents, among them the Service Assessment Criteria (SAC) , which establishes baseline criteria for general organizational conformity, identity proofing services, credential strength, and credential management services against which all CSPs will be evaluated.
The present document defines rules to be observed by those preparing ‘Profiles’ of the Service Assessment Criteria (i.e. ‘SAC Implementation Profiles’) to suit the needs of a specific community and which is intended to be formally adopted by the Kantara Initiative. The document may also be used as guidance by those who wish to prepare such profiles without any formal involvement with Kantara.
Filename: KI IAF-3410 v1.0_SAC_Profiling Rules.doc
This document has been prepared by Participants of Kantara Initiative. Permission is hereby granted to use the document solely for the purposes of adoption of and conformity to the Identity Assurance Framework. No rights are granted to prepare derivative works of this Specification. Entities seeking permission to reproduce portions of this document for other uses must contact Kantara Initiative to determine whether an appropriate license for such use is available.
Implementation or use of certain elements of this document may require licenses under third party intellectual property rights, including without limitation, patent rights. The Participants of and any other contributors to the Specification are not and shall not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights. This Specification is provided "AS IS," and no Participant in Kantara Initiative makes any warranty of any kind, expressed or implied, including any implied warranties of merchantability, non-infringement of third party intellectual property rights, and fitness for a particular purpose. Implementers of this Specification are advised to review Kantara Initiative’s website ( http://www.kantarainitiative.org/ ) for information concerning any Necessary Claims Disclosure Notices that have been received by the Kantara Initiative Board of Trustees.
Copyright : The content of this document is copyright of Kantara Initiative.
© 2011 Kantara Initiative.
2.3 Profile characteristics
3 PROFILING
3.1 Documenting the Profile
3.1.1 Document management
3.1.2 Referencing criteria
3.1.3 Means of expression & Ensuring coverage
3.2 Profiling examples
3.2.3 Example 3
3.2.4 Example 4
3.2.5 Example 5
3.2.6 Example 6
3.2.7 Example 7
4 Process for Profile Approval
4.1 Submit Proposal
4.2 IAWAG Liaison
4.3 Conflicts
4.4 IAWG Approval
5.1 SAC Supremacy
5.2 Ease of use
The Service Assessment Criteria (SAC) part of the Kantara Initiative Identity Assurance Framework (IAF) establishes baseline criteria for general organizational conformity, identity proofing services, credential strength, and credential management services against which all Credential Service Providers (CSP) will be evaluated.
Communities having specific interests may choose to establish ways of implementing provisions of their services which fulfill the SAC in a particular way, e.g. by including recitation of explicit policies, regulations which are complied with, etc. The practice of determining and documenting these specific implementation practices is known as ‘profiling’, and the resultant specification is a ‘SAC Implementation Profile’ (see § 2.2 , ‘Definition’).
The present document defines rules which shall be observed by those preparing ‘Profiles’ of the Service Assessment Criteria (i.e. ‘SAC Implementation Profiles’) to suit the needs of a specific community and which are intended to be formally adopted by the Kantara Initiative.
The document may also be used as guidance by those who wish to prepare such profiles without any formal involvement with Kantara, in which case all ‘shall’ forms of expression may be treated as being recommended, rather than mandatory.
This document assumes familiarity with the requirements, terminology and concepts of the IAF.
It is desirable to have a consistent approach to how such Profiles are recorded, so as to ease communication and understanding between organizations:
wishing to adopt a profile (and they may choose to adopt more than one);
wishing to cooperate in sharing the knowledge of how their community-specific interests are reflected and in how their services are being provided; and
studying such Profiles for other reasons.
This document will also benefit Kantara’s Accredited Assessors who might otherwise be faced with a variety of formats and consistency of presentation of profiling data.
These rules fulfill these needs.
In accordance with established best practice in the standards development world, and in keeping with usage established in key IAF documents, the following forms of expression are used with the meanings given:
The word " shall " indicates requirements strictly to be followed in order to conform to the specification and from which no deviation is permitted.
The word " should " indicates that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The word " may " indicates a course of action permissible within the limits of the specification.
This document also uses special terms which are defined in the IAF Glossary, http://kantarainitiative.org/confluence/download/attachments/41649275/Kantara+IAF-1100-Glossary.pdf
The foregoing leads to the deduction of the following definition:
SAC Implementation Profile - a description of implementation-specific choices and any supplementary requirements, expressed as being mandatory or optional, to be adopted by a particular community’s service providers, which strictly meets all applicable SAC requirements for specified service function(s) and assurance level(s).
Note – An SAC Implementation Profile (which, in the context of the Kantara IAF, can be referred-to simply as a ‘SIP’) is intended to serve as an implementation reference for Credential Service Providers when developing and operating their services and for Kantara’s Accredited Assessors when auditing those services for SAC conformity based upon a specific SIP.
Specific communities, which may be determined by service industry, regional (including jurisdictional) or other scoping considerations, will frequently wish to share common practices in the way in which standards and regulations, often established with a broad perspective, are put into practice. Those practices are intended to make more specific the requirements for implementation, but not to distort or evade the requirements of the reference(s) being implemented, nor shall they be permitted to do so.
In the context of profiling the SAC one shall have regard to the Assurance Level(s) and service component(s) (Identity Proofing and Credential Management Service Assessment Criteria) which are being profiled, since (at the time of preparing the present version of this document) twelve possible permutations of these two variables are possible (although in practice unlikely all to occur).
Thus, a SAC Profile shall have the following fundamental characteristics:
a) be tailored to the specific needs of the defined community;
b) state explicitly the Assurance Level(s) and service component(s) to which it applies;
c) facilitate a consistent approach towards evidencing conformity with the SAC;
d) uses terminology clearly indicating whether a provision is mandatory, recommended, or simply permissible [1] ;
e) not define any actions or processes which reduce or lessen the requirements of the SAC, which remain paramount;
f) may include comparable criteria not specifically outlined in the SAC that do not reduce or lessen the requirements .
Profiling is not fundamentally difficult. It requires a good understanding of the reference source (i.e. that which is being profiled) and of the subject area (i.e. the needs of the community, as previously labeled). Adoption of a standardized layout (as proposed herein) is simple. The art comes in succinctly defining the profile such that it is clear and unambiguous and does not challenge the intention of the original reference clause(s).
Good documentation practices require attention to certain fundamentals. The following requirements shall be observed:
Reference: The profile document shall have a reference number for ease of cataloging.
Title: The profile shall be titled as “SAC Profile - « owning community » - « description of application »”. Use of this style will assist cataloging, particularly if the description of application makes reference to the applicable Assurance Level and service component (see ‘Scope’, below).
Version: Each successive version shall be identifiable from its precedents, at whatever level issued (e.g. public, versus formal review draft, versus editorial draft). In the absence of any established practice the document shall adopt the version control procedures applied by KI.
Scope: The profile document shall include a description of the intended scope of applicability of the profile which shall, as a minimum, state all applicable Assurance Levels and service components. A profile may embrace different ALs for different service components, but the profile should be expressed as simply as possible and creating multiple profiles, with the applicable AL/component in the title should be considered. In all cases, the reference version of the SAC shall be cited.
The above-listed items shall be included within the profile specification, the first three of which shall be repeated on headers/footers throughout.
The primary objective in profiling is to identify a discrete clause within the reference source and then describe how it is to be specifically implemented or observed within the community to which the profile relates.
The SAC have been written such that each criterion has a discrete reference (ref. SAC §3.3) and where there are sub-criteria, each of these is uniquely identifiable by a list reference.
Development of a Profile therefore has the potential to address each criterion and sub-criterion within the SAC. The following clauses set forth how this may be addressed.
In the case where each criterion can usefully be profiled the question of completeness hardly arises (reference criteria lists are available in the SAC).
Where a subset of the criteria are to be profiled the question arises, “How does one know that the profiled criteria in the specification are actually all those intended to be included?” One of the following recommendations shall be adopted:
a) Produce a community-specific version of the original SAC (since this is available online as a resource document from which to work) retaining all of its requirements as stated and indicate the profiling requirements as distinctly identifiable text (e.g. with the community qualifier and italicized text, all enclosed in square brackets);
b) Provide a table only of the criteria tags but explicitly include ALL such tags and for those for which there is no determined profile, state so, or otherwise provide the profile specification. By this approach less impact may be suffered if the SAC is revised;
c) Provide a table of only the required profile specifications and refer to an annex which lists ALL criteria in a table and simply indicates by an obvious method those for which a profile has been included. This solution will require less text and will not distract from what actually has been profiled. Similarly, by this approach less impact may be suffered if the SAC is revised.
In all cases caution should be exercised to ensure that revisions to the SAC are tracked and the community-specific version revised accordingly.
The profile specification shall adopt the terminology used in the referenced criterion, so as to eliminate any potential ambiguity being introduced by the use of alternative phrases or descriptors.
The following examples illustrate each of the three forms of expression given above, in varying circumstances. These examples adopt the forms of expression set out in § 2.1 .
In this example, adopting method § 3.1.3 a) , the profiling simply imposes a pre-defined format and set of clauses which will be chosen as the specific basis for conforming to the SAC requirement, accomplished by modifying a copy of the full SAC, per § 3.1.3 . a) .
AL1_CO_NUI#020 Service Definition inclusions
Make available a Service Definition for the specified service containing clauses that provide the following information:
a) a Privacy Policy [PGC: which shall adopt without modification the format and standard clauses from the «PrivacyGuardian Community»’s latest published Privacy Policy ].
In this example, based on method § 3.1.3 b) , the same profiling as above is accomplished by having a separate, tabulated, profiling specification for each individual criterion.
Criterion tag
Profiled implementation
AL1_CO_NUI#010
AL1_CO_NUI#020
Re. item (a): The organisation’s Privacy Policy shall adopt without modification the format and standard clauses from the «PrivacyGuardian Community»’s currently published Privacy Policy.
AL1_CO_NUI#030
In this example, reflecting method § 3.1.3 c) , the same profiling as in § 3.2.1 is accomplished by having a separate, tabulated, profiling specification for only those criteria which had explicit profiling, per § 3.1.3 b).
Therefore, there is an implicit summary list elsewhere in the specification which should appear like this:
Table 1. CO-SAC - AL1 Profiling
Profiled?
AL1_CO_ESM#010
AL1_CO_ESM#020
AL1_CO_ESM#030
AL1_CO_ESM#040
AL1_CO_ESM#055
AL1_CO_NUI#040
AL1_CO_NUI#050
AL1_CO_SCO#020
In this example, adopting method § 3.1.3 a) , the profiling imposes a pre-defined format and set of clauses which will fulfill all policy requirements in sub-clause a) and then requires adherence to a ‘Reference Service Provision Agreement’ (which one imagines the community to have created for its members’ use) and specific clauses of this agreement against the eight sub-clauses e) to l) of the SAC requirement. This is accomplished by modifying a copy of the full SAC, per § 3.1.3 . a) .
AL2_CO_NUI#020 Service Definition inclusions
a) Privacy , Identity Proofing & Verification, and Revocation and Termination Policies [PGC: which shall adopt without modification the format and standard clauses from the «PrivacyGuardian Community»’s Service Provision Policies reference text which addresses, inter alia , each of these topic areas ] ;
b) the country in or legal jurisdiction under which the service is operated;
c) if different from the above, the legal jurisdiction under which subscriber and any relying party agreements are entered into;
d) applicable legislation with which the service complies;
e) obligations incumbent upon the CSP [PGC: which should, as a minimum, include clauses AA - BB of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ] ;
f) obligations incumbent upon the subscriber [PGC: which should, as a minimum, include clauses CC - DD of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ] ;
g) notifications and guidance for relying parties, especially in respect of actions they are expected to take should they choose to rely upon the service [PGC: which should, as a minimum, include clauses EE - FF of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ] ;
h) statement of warranties [PGC: which should, as a minimum, include clauses GG - HH of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ] ;
i) statement of liabilities toward both Subjects and Relying Parties [PGC: which should, as a minimum, include clauses II - JJ of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ] ;
j) procedures for notification of changes to terms and conditions [PGC: which should, as a minimum, include clauses KK - LL of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ] ;
k) steps the CSP will take in the event that it chooses or is obliged to terminate the service which should, as a minimum, include clauses MM - NN of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ;
l) availability of the specified service per se and of its help desk facility [PGC: which should, as a minimum, include clauses OO - PP of the «PrivacyGuardian Community»’s Reference Service Provision Agreement ] .
In this example, reflecting method § 3.1.3 c) , the same profiling as above is accomplished by having a separate, tabulated, profiling specification for each individual criterion, and in this case (only) for the applicable sub-clauses, per § 3.1.3 . b).
AL2_CO_NUI#020
Re. item (a): which shall adopt without modification the format and standard clauses from the «PrivacyGuardian Community»’s Service Provision Policies reference text which addresses, inter alia, each of these topic areas.
Re. item (e): which should, as a minimum, include clauses AA - BB of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
Re. item (f): which should, as a minimum, include clauses CC - DD of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
Re. item (g): which should, as a minimum, include clauses EE - FF of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
Re. item (h): which should, as a minimum, include clauses GG - HH of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
Re. item (i): which should, as a minimum, include clauses II - JJ of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
Re. item (j): which should, as a minimum, include clauses KK - LL of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
Re. item (k): which should, as a minimum, include clauses MM - NN of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
Re. item (l): which should, as a minimum, include clauses OO - PP of the «PrivacyGuardian Community»’s Reference Service Provision Agreement.
All of the examples so far have taken a clause and made it more explicit. The following example, adopting method § 3.1.3 a) , takes a slightly different path, in an assumed ‘Health Insurance Community’. The SAC requirement permits a degree of choice as to how the clause is fulfilled, but the profile removes that element of choice and imposes a specific form of conformity and, moreover, specifies particular controls which should be taken into consideration when establishing and operating the ISMS. The dictated solution therefore fulfills the SAC requirement by meeting, explicitly, one of the available options.
AL3_CO_ISM#120 Best Practice Security Management
Have in place an Information Security Management System (ISMS), or other IT security management methodology recognized by a government or professional body, that follows best practices as accepted by the information security industry and that applies and is appropriate to the CSP in question. All requirements expressed in preceding criteria in this section must inter alia fall wholly within the scope of this ISMS or selected recognized alternative.
[HIC: Shall have in place an ISMS currently certified as being conformant to ISMS 27001, per the latest ISO-published version at the time of last certification, which includes an SoA addressing all controls listed in IS27001 Annex A, which has taken into consideration the guidance given in ISO/IEC 27799 (version requirements as per certification) and incorporates the controls listed in Extended Control Sets HIC-ESC-27001/HIPAA and HIC-ESC-27001/PIPEDA .]
In this final example, which could apply to any of the methods described in § 3.1.3 c) , are instances of acceptable and unacceptable profile clauses.
Consider the CM_SAC clause AL3_CM_RVP#060 Record Retention , which states:
Retain, securely, the record of the revocation process for a period which is in compliance with:
a) the records retention policy required by AL2_CM_CPP#010, and;
b) applicable legislation;
and which, in addition, must be not less than the duration of the subscriber’s account plus 7.5 years.
A profile addressing this clause might state:
AL3_CM_RVP#060: Community members shall retain revocation records for a minimum period of 10 years after the closure of a subscriber’s account.
This would be an acceptable profiling clause because the retention period exceeds that of the SAC’s requirement.
On the other hand, were the profile to state:
AL3_CM_RVP#060: Community members shall dispose of revocation records 5 years after the closure of a subscriber’s account.
this would not be permitted because the stated retention period, being shorter than that required by the SAC, would render any implementer adopting that retention period to be non-compliant with this SAC criterion.
Users will readily see, without further examples, how the SAC requirements can be made more concrete and relevant in specific instances and can map the generic requirements onto much more specific needs, suiting particular communities of interest. Other instances might list specific controls to be from other sources in response to specific SAC requirements (e.g. citing NIST SP 800-53 controls).
Any group that is seeking to create a profile of the Service Assessment Criteria should complete and submit the SAC Profile Submission Form. This form includes information such as the specific community of interest or jurisdiction that is requesting the profile and a brief description of why the profile is required. This form, will provide the IAWG the opportunity to review the request, and assign a liaison to the Profile Creation Work Group that is specifically associated with the particular subject matter of the profile.
Based on the information submitted on the proposal form, the IAWG will poll the membership and determine the most appropriate liaison assigned to the work effort associated with the profile. The IAWG liaison will also serve as the Identity Assurance SME and resource for the PCWG. The liaison will also serve as a communication vehicle between the IAWG and the Profile Creation Work Group (PCWG). As a result the liaison will report back to the IAWG on the PCWGs work efforts on at least a monthly basis or some time frame more appropriately associated with the time frame established by the PCWG for the completion of the profile. The report given by the liaison should focus on the status of the completion of the profile and also any potential issues that have arisen within the PCWG that could require additional work by the IAWG. This ongoing communication is necessary to ensure that at the point of final submission of the profile to the IAWG for inclusion in the IAF stack of documents, there are no surprises.
Any conflicts identified between the SAC and the profile created by the PCWG, should attempt to be resolved between the two groups. However, there will potentially be instances in which potential conflicts could pose an issue regarding Kantara interoperability with other Trust Frameworks. In these instances escalation to either Katnara Leadership or external partners would be required. required. In these circumstances conflicts should be noted and tracked through resolution.
Upon final submission to the IAWG and resolution of all issues, the IAWG will take a vote on the proposed profile. The approval of the profile by the IAWG will officially adopt the profile as a component to the stack of IAF documents.
Little guidance is required, but the following points are made as much for the benefit of CSPs seeking an assessment of their services as to aid Assessors in their task.
Nothing in a profile shall avoid conformity to any criteria within the IAF unless there is a clear stand-alone argument that a criterion does not apply. Profiling is not a means to develop an alternative to, or to void, a criterion; it is intended to provide a means by which to conform in a consistent manner, typically by describing a more explicit level of requirement and/or means to achieve conformity.
Adoption of a consistent format (i.e. that put forth in this specification) will make easier the job of almost all parties involved in the provision, use, inter-operation and assessment of identity services.
[1] i.e. adopt the forms of expression set forth in § 2.1 , ‘Terminology’
{"serverDuration": 136, "requestCorrelationId": "c87591ad3077032b"}