UNC Identity Federation

UNC Identity Federation

Overview ............................................................................................................................................... iv 1. Purpose & Definition ......................................................................................................................... 1

1. Background & Purpose ............................................................................................................ 1 2. Definition ................................................................................................................................. 1

2. Participant Operational Practices ....................................................................................................... 2 1. Purpose ..................................................................................................................................... 2 2. Overview .................................................................................................................................. 2 3. Required Basic Information ..................................................................................................... 2 4. Level of Assurance Guidelines ................................................................................................ 5

4.1. Federal Standards ........................................................................................................ 5 4.2. Determining Level of Assurance ................................................................................. 6

4.2.1. Assess Risk ..................................................................................................... 6 4.2.2. Map Risk to Assurance Level ......................................................................... 6 4.2.3. Validate ........................................................................................................... 7 4.2.4. Periodically Reassess ...................................................................................... 7

4.3. Conclusion ................................................................................................................... 8 3. Federation Operations ........................................................................................................................ 9

1. Policies & Practices ................................................................................................................. 9 1.1. Role of UNC - General Administration ....................................................................... 9 1.2. Governance .................................................................................................................. 9 1.3. Participation ................................................................................................................. 9

1.3.1. Eligibility ........................................................................................................ 9 1.3.2. Joining the Federation ..................................................................................... 9 1.3.3. Participation Fees ............................................................................................ 10

1.4. Registration .................................................................................................................. 10 1.4.1. Participants ...................................................................................................... 10 1.4.2. Registered Systems ......................................................................................... 11

2. Technical Infrastructure ........................................................................................................... 11 3. Technical Operations ............................................................................................................... 11 4. Certificate Authority Operations .............................................................................................. 12

4.1. Overview ..................................................................................................................... 12 4.1.1. Root Certificate Profile ................................................................................... 12 4.1.2. Credential Lifetime ......................................................................................... 13 4.1.3. Security ........................................................................................................... 13 4.1.4. Auditing .......................................................................................................... 14

4.2. Certificate Signing ....................................................................................................... 14 4.3. Certificate Revocation ................................................................................................. 15 4.4. Recovery from CA Breach .......................................................................................... 15

4. Identity Attributes .............................................................................................................................. 16 1. Overview .................................................................................................................................. 16 2. Attribute Summary ................................................................................................................... 16

2.1. eduPersonScopedAffiliation ........................................................................................ 17 2.1.1. Description ...................................................................................................... 17 2.1.2. Usage Notes .................................................................................................... 17

2.2. eduPersonPrincipalName ............................................................................................. 17 2.2.1. Description ...................................................................................................... 17 2.2.2. Usage Notes .................................................................................................... 17

2.3. eduPersonTargetedID .................................................................................................. 17 2.3.1. Description ...................................................................................................... 17 2.3.2. Usage Notes .................................................................................................... 18

2.4. sn ................................................................................................................................. 18 2.5. givenName ................................................................................................................... 18 2.6. displayName ................................................................................................................ 18 2.7. mail .............................................................................................................................. 18

2.7.1. Description ...................................................................................................... 18 2.7.2. Usage Notes .................................................................................................... 18

3. Valid Domains ......................................................................................................................... 18 References ............................................................................................................................................. 20 Glossary ................................................................................................................................................. 21

iii

Overview

The following document outlines the full definition of the UNC Identity Federation from its abstract purpose to specific operational details in both functional and technical form. The purpose of this document is to provide definition and structure around the creation and maintenance of the Federation.

iv

Chapter 1. Purpose & Definition

1. Background & Purpose

The University of North Carolina is comprised of sixteen universities, one high school, and one system office. Each of these constituents maintain separate technology infrastructure including servers, networking devices, and enterprise resource and planning (ERP) systems. Therefore, each constituent has internally issued computer accounts and credentials designed to access systems specific to each member. Credentials issued by one member are not valid for any other member within the system.

Due to various economic pressures, inter-institutional communication and resource sharing is rapidly increasing as a means of providing cost effective solutions for both individual entities as well as the aggregate system as a whole. As such, students, staff, and faculty are increasingly consuming electronic services provided by other members of the community. However, the lack of a centralized credential provisioning service makes these scenarios difficult to create and administer since service providers cannot securely authenticate and authorize users.

In particular, the need to increase course availability to existing UNC students by allowing inter-institutional registration for online courses has provided an immediate need to enable this type of credential sharing between the UNC constituents. However, establishing a centralized credential provisioning, authentication, and authorization service is not feasible given the current state of IT resources, personnel resources, economic resources, and organizational preparedness. Given these shortcomings and the imminent need to provide these distributed services, the organization must pursue a federated approach.

This federated approach enables each independently operating entity to maintain its credential provisioning autonomy while still participating in system-wide efforts.. In other words, the federated approach enables each entity to offer services directly to other entities while providing its own faculty, staff, and students access to services offered by other cooperating members.

2. Definition

The UNC Identity Federation provides the metadata definition and operational infrastructure needed to enable federated service delivery among the constituent members of the University of North Carolina. The scope of this federation is not intended to be the long term solution for UNC; that strategic direction has not been fully vetted and determined. While this is a tactical deployment designed to meet specific objectives, this UNC Identity Federation is designed to appropriately scale into the strategic solution if that outcome is desired by all the parties involved. This tactical deployment will provide UNC a large amount of information and experience in the world of identity management and position it to optimize the strategic vision.

1

Chapter 2. Participant Operational Practices

1. Purpose

This chapter outlines the operational practices from the participant perspective. It provides the metadata about operational practices that each participant must complete for membership; these practices outline how identities are created and maintained at each participant. Answers to these questions enable all participating service providers to make a sound judgement on the level of assurance (LOA) that an authenticated user is truly the correct individual. In addition, the document describes the standards upon which each organization must meet for participation. For consistency with other higher education initiatives, this document draws from its sister document for the InCommon Federation [InCommon_POP].

2. Overview

Participation in the UNC Federation (“Federation”) enables the participant to use Shibboleth identity attribute sharing technologies to manage access to on-line resources available to the UNC community. One goal of the Federation is to develop, over time, community standards for such cooperating organizations to ensure shared attribute assertions are sufficiently robust and trustworthy to manage access to important protected resources. As the community of trust evolves, the Federation expects that participants eventually should be able to trust each other's identity management systems and resource access management systems as they trust their own.

As part of the fundamental expectation of the Federation, each member must provide authoritative and accurate attribute assertions to other participants providing services to this Federation. In turn, the participants receiving these assertions should protect these attributes from public dissemination as well as preserve their privacy by adhering to the constraints placed on them by either the Federation or the originating source of information. Toward this end, each participating member is required to accurately and completely maintain a set basic information concerning the operational policies of issuing authoritative identities to its constituents. This information about each member will be available to all other members so that each institution can determine an accurate level of assurance (LOA) for the other member organizations. However, this basic information will not be publicly available.

Two criteria for trustworthy attribute assertions by Credential Providers are: (1) that the identity management system fall under the purview of the organization’s executive or business management, and (2) the system for issuing end-user credentials (e.g. PKI certificates, userids/passwords, Kerberos principals, etc.) specifically have appropriate risk management measures (for example authentication and authorization standards, security practices, risk assessment, change management controls, audit trails, etc.).

All service providers receiving attribute assertions from another organization will respect that organization's policies, rules, and standards regarding the protection and use of that data. Furthermore, such information can only be used in accordance with the purpose for which it was provided and may not be shared with third parties or aggregated for marketing purposes without the explicit permission of the identity information provider.

3. Required Basic Information

The following set of questions must be answered in sufficient detail by each Federation member; this information will be posted on a secured website to for the availability of all participating organizations. Each member is required to maintain this information as policies and procedures change within that organization. Consequently, each member will be required to modify and/or certify the validity of the information on an annual basis. Each member will have access to a web-based interface that will enable on-demand modification of this information. This web-based interface will contain the following pieces of information:

1. Identification Information

1.a. Participant identification

2

Participant Operational Practices

1.a.i. Organization's name

1.a.ii. Accurate "as of" date

1.b. Additional information URL (a link to additional information pertaining to identity management and/or privacy policies regarding the use of personal information)

1.c. Executive Contact Information - An individual responsible for answering questions about the participants identity management system or resource access management policy or practice.

1.c.i. Name

1.c.ii. Title / Role

1.c.iii. Email Address

1.c.iv. Phone

1.c.v. Fax

1.d. Technical Contact Information - An individual responsible for answering and monitoring day-to-day operations of the identity provider.

1.d.i. Name

1.d.ii. Title / Role

1.d.iii. Email Address

1.d.iv. Phone

1.d.v. Fax

2. Identity Provider Information - The most critical responsibility that an Identity Provider participant has to the Federation is to provide trustworthy and accurate identity assertions. Each service provider must know how these electronic identity credentials are issued and the reliability of the information associated with a given credential.

2.a. Community Membership

2.a.i. Electronic Identity - How do you define the set of people who are eligible to receive an electronic identity?

2.a.ii. Member of Community - This is an assertion that might be offered to enable access to resources made available to individuals who participate in the primary mission of the university or organization. For example, this assertion might apply to anyone whose affiliation is “current student, faculty, or staff.”

What subset of persons registered in your identity management system would you identify as a “Member of Community” in Shibboleth identity assertions to other participants? Please specifically consider individuals who engage in sponsored research when answering this question.

2.b. Electronic Identity Credentials

2.b.i. Establishment - Please describe in general terms the administrative process used to establish an electronic identity that results in a record for that person being created in your electronic identity database? Please identify the office(s) of record for this purpose. For example, “Registrar’s Office for students; HR for faculty and staff.” Please specifically consider individuals who engage in sponsored research when answering this question.

2.b.ii. Credential Type(s) - What technologies are used for your electronic identity credentials (e.g., Kerberos, userID/password, PKI, etc.) that are relevant to Federation activities? If more than one type

3

Participant Operational Practices

of electronic credential is issued, how is it determined who receives which type? If multiple credentials are linked, how is this managed and recorded?

2.b.iii. Password - If your electronic identity credentials require the use of a secret password or PIN, the following questions are applicable.

2.b.iii.A. Encryption - Are there circumstances in which that secret would be transmitted across a network without being protected by encryption (i.e., “clear text passwords” are used when accessing campus services), please identify who in your organization can discuss with any other Participant concerns that this might raise for them.

2.b.iii.B. Strength - What policies and rules are in place to ensure passwords relevant to Federation activities are sufficiently strong and effective against guessing and brute force attacks?

2.b.iii.C. Change Frequency - How often are users required to change passwords that are relevant to Federation activities? How are these durations enforced?

2.b.iv. Single Sign On - If you support a “single sign-on” (SSO) or similar campus-wide system to allow a single user authentication action to serve multiple applications, and you will make use of this to authenticate people for Federation Service Providers, please describe the key security aspects of your SSO system including whether session timeouts are enforced by the system, whether user-initiated session termination is supported, and how use with “public access sites” is protected.

2.b.v. Uniqueness - Are your primary electronic identifiers for people, such as “net ID,” eduPersonPrincipalName, or eduPersonTargetedID considered to be unique for all time to the individual to whom they are assigned? If not, what is your policy for re-assignment and is there a hiatus between such reuse?

2.b.vi. Example Applications - Please identify typical classes of applications for which your electronic identity credentials are used within your own organization.

2.c. Electronic Identity Database

2.c.i. Creation & Management - How is information in your electronic identity database acquired and updated? Are specific offices designated by your administration to perform this function? Are individuals allowed to update their own information on-line?

2.c.ii. Public Information - What information in this database is considered “public information” and would be provided to any interested party?

2.d. Attribute Assertions - Would you consider your attribute assertions to be reliable enough to:

• Control access to on-line information databases licensed to your organization?

• Be used to purchase goods or services for your organization?

• Enable access to personal information such as student loan status?

2.e. Privacy Policy - Federation Participants must respect the legal and organizational privacy constraints on attribute information provided by other Participants and use it only for its intended purposes.

2.e.i. Restrictions - What restrictions do you place on the use of attribute information that you might provide to other Federation participants?

2.e.ii. Release Policy - What policies govern the use of attribute information that you might release to other Federation participants? For example, is some information subject to FERPA or HIPAA restrictions?

3. Service Provider Information - Service Providers are trusted to ask for only the information necessary to make an appropriate access control decision, and to not misuse information provided to them by Identity Providers. Service Providers must describe the basis on which access to resources is managed and their practices with respect to attribute information they receive from other Participants.

4

Participant Operational Practices

3.a. Required Attributes - What attribute information about an individual do you require in order to manage access to resources you make available to other Participants? Describe separately for each resource ProviderID that you have registered.

3.b. Attribute Use - What use do you make of attribute information that you receive in addition to basic access control decisions? For example, do you aggregate session access records or records of specific information accessed based on attribute information, or make attribute information available to partner organizations, etc.?

3.c. Attribute Masking - What human and technical controls are in place on access to and use of attribute information that might refer to only one specific person (i.e., personally identifiable information)? For example, is this information encrypted?

3.d. Super-user Administration - Describe the human and technical controls that are in place on the management of super-user and other privileged accounts that might have the authority to grant access to personally identifiable information?

3.e. Breach Procedures - If personally identifiable information is compromised, what actions do you take to notify potentially affected individuals?

4. Other Information

4.a. Technical Standards, Versions and Interoperability - Identify the version of Internet2 Shibboleth code release that you are using or, if not using the standard Shibboleth code, what version(s) of the SAML and SOAP and any other relevant standards you have implemented for this purpose.

4.b. Other Considerations - Are there any other considerations or information that you wish to make known to other Federation participants with whom you might inter-operate? For example, are there concerns about the use of clear text passwords or responsibilities in case of a security breach involving identity information you may have provided?

4. Level of Assurance Guidelines

Since each Federation member will provide the basic information listed above, then all service providers within this Federation will be able to make an informed decision about the confidence that an authenticated user is indeed the correct individual. This confidence is also know as the level of assurance. Each application (or service provider) must evaluate its application needs to determine if the level of assurance provided by each Federation member meets these security requirements. The remainder of this section provides background and guidance in making this type of determination.

4.1. Federal Standards

This section summarizes the US Office of Management and Budget's (OMB) memorandum concerning guidance for e-authentication within the federal government [OMB-04-04]. In addition, it summarizes the accompanying National Institute of Standards and Technology (NIST) recommendations [NIST-04-04]. These documents define the federal standard for security level access to electronic applications and information:

1. Level 1 - Little or no confidence in the asserted identity’s validity

2. Level 2 - Some confidence in the asserted identity’s validity

3. Level 3 - High confidence in the asserted identity’s validity

4. Level 4 - Very high confidence in the asserted identity’s validity

These levels of assurance are applicable for two different types of authentication:

1. Identity authentication - The process of confirming a person's unique identity.

2. Attribute authentication - The process of confirming that the unique person (once the identity is authenticated) is correctly represented by the claimed attributes.

5

Participant Operational Practices

Furthermore, these documents identify the following categories of harm and impact due to purposeful or inadvertent mis-authentication:

• Inconvenience, distress, or damage to standing or reputation • Financial loss or agency liability • Harm to agency programs or public interests • Unauthorized release of sensitive information • Personal safety • Civil or criminal violations

The following section provides the guidance needed for each service provider to perform a risk analysis of an application to determine the required level of assurance for the application at hand. However, no all inclusive template exists for this type of analysis as it largly depends on the environment and application-specific requirements.

4.2. Determining Level of Assurance

Due to the distributed nature of the Federation, service providers are not able to perform either identity or attribute authentication first-hand. As such, the service provider must TRUST the entity supplying both the identity assertions and the attribute assertions. However, trust between people and organizations is difficult to establish and maintain. By transparently disclosing operating policies and practices, federated entities can independently evaluate this information to determine a level or assurance that the asserted credentials are both precise and accurate. The remainder of this section provides the framework needed to make these types of determinations.

4.2.1. Assess Risk

For each of the six categories listed above, all applications should be analyzed to determine the potential impacts of a security breach. The impact for each category will be dramatically different based on the type of application, the information it requires, and the manner with which individuals access it. The direct impact measurement scale used by the federal government is defined as:

• Low Risk • Moderate Risk • High Risk

For a detailed discussion of the exact meaning of each impact type on the individual categories, please refer to the [OMB-04-04] memorandum. Once the degree of impact is determined, then one must assess the likelihood that this type of error/breach will occur.

4.2.2. Map Risk to Assurance Level

While the degree and frequency of a breach both determine the needed level of assurance, the degree is often the dominant factor assuming the likelihood is greater than 0 percent. Therefore, the following table can be used to determine the appropriate level of assurance required to meet the minimum security requirements:

Table 2.1. Maximum Potential Impact Profiles

Assurance Level Potential Impact Categories for

Authentication Errors 1 2 3 4

Inconvenience, distress, or damage

to standing or reputation

Low Mod Mod High

Financial loss or agency liability

Low Mod Mod High

Harm to agency programs or public

N/A Low Mod High

6

Participant Operational Practices

interests Unauthorized release

of sensitive information

N/A Low Mod High

Personal safety N/A N/A Low Mod/High Civil or criminal

violations N/A Low Mod High

Once the appropriate assurance level has been identified, the information provided by each Federation member must be evaluated in order to determine if it meets the required level. While all of the information must be taken into account, the type of authentication token used by each member plays a dramatic role in determination of the assurance level. While the Federation does NOT specify the required token type, all such credentials will likely be based on userids and passwords, which is in contrast to cryptographically signed name badges, software certificates or other more secure forms of authentication. The following table maps various authentication tokens to the familiar assurance levels:

Table 2.2. Token Type Assurance Mappings

Assurance Level Allowed Token Types 1 2 3 4

Hard Crypto Token Yes Yes Yes Yes Soft Crypto Token Yes Yes Yes - One-time Password Device

Yes Yes Yes -

Strong Password Yes Yes - - PIN Yes - - -

This table implies that the highest assurance level provided by the Federation (assuming userid and password authentication) is level 2 (some confidence in the asserted identity’s validity). Applications that require higher levels of assurance should NOT use the Federation as a means of authentication. In everyday usage, an assure level of 2 means that the application is reasonably confident the true identity of the authenticated individual is equivalent to the identity asserted by the identity provider.

However, reasonable assurance of an individual's identity does NOT necessarily imply reasonable attribute authentication assurance. In other words, the attribute assurance is more dependent on the internal processes of the identity provider to keep the information accurate and fresh. For example, the "current address" of an authenticated is user is only as accurate as the process for collecting, verifying, and maintaining that data from the original identity provider. Therefore, if authorization decisions are made based on asserted identity attributes, then the service provider must take the maintenance of this data into account when determining if the actual assurance level meets the minimum requirements for the application in question.

4.2.3. Validate

Once an application has been implemented, the service provider should conduct a final analysis to ensure if implementation decisions did not negatively affect the security of the application. This analysis should verify that the actual assurance level of the application meets the predefined minimum.

4.2.4. Periodically Reassess

Change is inevitable in both application requirements and business processes. As a result, the assurance level of all applications should be re-evaluated on a periodic basis. This re-evaluation should include both the required assurance level and the actual assurance level. Evaluating the actual level ensures the application and its data is consistent with the all previous assumptions. Naturally, a change in required level will necessitate changes to the authentication structure. On the other hand, the actual assurance level depends on the operating policies and practices of the Federation members as well as the application implementation decisions. The service provider should ensure changes in these business practices have not altered the actual assurance level of the delivered application.

7

Participant Operational Practices

8

4.3. Conclusion

In theory, the Federation can provide any level of assurance (1-4) required of an application. However in practice, the local identity provider's likely authentication method (userid and password) restricts usage to applications requiring at most level 2 security. When creating a service to be consumed by Federation members, that service provider must follow these steps in order to establish an appropriate level of assurance for the application in question:

1. Conduct a risk analysis

2. Map risks to a level of assurance

3. Evaluate participating members to ensure minimum levels of assurance are met

4. Validate post implementation

5. Reassess periodically

Since each entity is required to provide a basic set of pertinent metadata, then service providers will have the information required to make an informed decision during the process listed above. Furthermore, transparency between members will facilitate better levels of assurance in the future as business processes are continuously revised and improved.

Chapter 3. Federation Operations

1. Policies & Practices

This section provides a high level description of the creation and management of the UNC Federation. Subsequent sections will provide additional technical details, but ultimate specific details and logistics will be left to the discretion of the managing entity, UNC - General Administration (GA). The goal of this section is to provide insight and understanding into Federation operations to enable members to sufficiently interact with the Federation. In addition, the transparent nature of the Federation will help ensure security and trustworthiness of the asserted attributes.

1.1. Role of UNC - General Administration

UNC - General Administration (GA) will serve as the administrative entity for the Federation. GA will maintain the authoritative list of registered participants, service providers, and identity providers. These lists will be appropriately signed by GA's certificate authority (CA) to ensure authenticity of the data. GA will be responsible for providing the necessary web interfaces to enable registry of service providers and identity providers for each participating member.

1.2. Governance

The day-to-day operations along with routine decision making is handled by GA. However, the UNC Chief Information Officer's (CIO) council will have the ability to steer the Federation to the benefit of the collective community. The CIO council will have the opportunity to request changes, develop position papers, provide advice, and prioritize implementation schedules. As such, General Administration acts as the executor of these strategic directions and makes the technical implementation decisions required to meet the stated needs.

1.3. Participation

1.3.1. Eligibility

All participants must be a constituent member of the University of North Carolina. The UNC Center for Public Television (UNC-TV) is consider a constituent member in this context. At this time no outside entities are granted admittance to the Federation. However, outside entities may join with the sponsorship of an existing UNC system member. Please see the subsequent section for a description of the process that will ensue in the event an outside entity wishes to join the Federation.

1.3.2. Joining the Federation

As previously stated, outside entities will require sponsorship of an existing UNC constituent in order to join the Federation. The following process will be followed in order to determine admission:

1. Apply for Admission - The joining entity will complete the admissions application in conjunction with their sponsoring entity. Once completed, that entity will officially submit it to General Administration. The admissions application will collect the following information:

• From Outside Entity

• Introductory statement

• Reason for requesting membership

• Benefits that the federation will gain if granted membership

• Detailed responses to all the metadata from Section 3, “Required Basic Information”

• From Sponsoring UNC Institution

9

Federation Operations

• Reason for sponsoring

• Explanation of benefits to the institution

2. Review by Panel - General Administration will work with the CIO council to develop a 5-6 member review panel. This panel will take the request under advisement to review the documentation and evaluate the appropriateness of the request. If the volume of these requests is high, the panel might become a standing subcommittee of the CIO council. Alternatively under a low volume of requests, panel membership will be more fluid and staffed on a case-by-case basis. The CIO council, in conjunction with General Administration, will have the ability to make this staffing determination based on the average volume of requests. The panel will make a recommendation about the inclusion or exclusion of the entity based on the admissions application and subsequent internal discussions. This recommendation will be in the form of a written position statement crafted by the chair of the panel.

3. Review by CIO Council - The CIO council will receive the written statement from the review panel and proceed to discuss and ultimately vote on the admission or exclusion of the entity. This vote includes the CIOs from the 16 Universities, UNC Public Television, General Administration, and the North Carolina School of Science and Math. A majority of votes is needed to carry the motion in either direction. CIO members are allowed to vote: "Include", "Exclude", or "Present". In the event of a tie, the CIO from General Administration will break the tie.

4. Proceed if Accepted - If the CIO council approves the request, then the external entity is responsible for paying the required participation fees and proceeding with the remainder of the registration process (completing full metadata, registering systems, etc).

5. Appeal if Denied - If the CIO council denies the request, then the external entity has the ability to appeal the decision by submitting a formal written statement to General Administration. This statement should explain the reasons for appeal and any new evidence that the review panel should consider. This action will return the process to step #2 and continue.

1.3.3. Participation Fees

The constituent members of UNC are not be required to pay any additional participation fees for the maintenance of the Federation. Entities not directly affiliated with UNC may be charged an additional participation fee to cover the operating costs of maintaining their membership. The exact amount of this fee will be set by the governing body after deliberating with the day-to-day operating personnel; these fees will be established as part of the evaluation process of the initial joining request. On an annual basis, the Federation has the option to revisit these fees based changing market conditions and operating costs. This section will be replaced with the official fee policy once that determination has been made by the steering committee.

1.4. Registration

1.4.1. Participants

Each participating member of Federation is required to register both an executive member and a technical member with General Administration. The executive member (likely the CIO) will represent the member in high level matters concerning Federation policy and decision making. The technical member will serve as the day-to-day technical contact responsible for ensuring providers are running and delivering accurate assertions from the underlying identity database. General Administration will establish out of band communication with these officers to enhance the level of assurance surrounding the validity of the member. See Section 3, “Technical Operations”, for details concerning the establishment of these officers.

1.4.1.1. Digital Certificates

Successful operation of the Federation will require signed digital certificates for: 1) attribute signing, 2) attribute encryption, and 3) normal web server SSL encryption. General Administration will serve as the certificate authority (CA) for the digital certificates required for attribute signing and attribute encryption. Each member will have the appropriate web interface to upload Certificate Signing Requests (CSR) for subsequent signing and delivery. General Administration will provide this framework for both identity providers (IDP) and service providers (SP) who are members to the Federation. These digitally signed public keys will be part of the metadata files that create the trust fabric for the Federation.

10

Federation Operations

Each member will be required to supply its own web server SSL certificates for both its IDPs and SPs. These SSL certificates must be signed by a well-known CA in order to avoid unwanted security notifications with the user's web browser. Since General Administration is not a globally recognized certificate authority, then these certificates must be obtained by alternate means.

1.4.2. Registered Systems

The purpose of the federation is to create an authoritative repository for all valid identity providers and service providers with the University of North Carolina. As such, each entity is responsible for registering all such systems with the Federation metadata. As discussed in the previous section, this authoritative repository is created by signing certificate requests with the federation certificate authority. Therefore, each registered system represents one public/private key pair with appropriate signature from the authority.

To accomplish this system registration, the technical contact for each entity will be provided access to the federation administrative web interface. This interface will enable the technical contact to add, update, and remove, and revoke registered systems from the federation. General Administration will make efforts to ensure that certificate signing requests are valid and appropriate by confirming such electronic requests via an alternate means such as a telephone call or an email. General Administration will maintain a production and development version of the federation metadata for the convenience of its members.

2. Technical Infrastructure

In order to carry out operations of the Federation, General Administration will provide an apache web server to provide the required communication infrastructure. This web server will supply the XML metadata needed for authoritative attribute authorizations as well as the discovery service required to connect individual users with the appropriate identity provider. In addition, this web server will be responsible performing the necessary certificate authority operations as outlined below.

General Administration will provide disaster recovery for this hardware at an alternate site. Specifically, the federation infrastructure will have dedicated resources at this alternate location to enable recovery from a catastrophic loss within one business day plus time to fully propagate DNS changes. Every 24 hours, all federation data will be securely mirrored from the production server to the disaster recovery server.

3. Technical Operations

The following list represents the sequential technical steps required to bring a new member into the Federation and add its identity provider.

1. Provision Administrative Account - Each member institution will have one administrative account that will be required to perform the necessary administrative actions. The technical contact for the member should be the only individual who knows the authentication credentials.

1.a. Username - General Administration (GA) will issue a unique userid that is semantically representative of the entity.

1.b. Password 1.b.i. GA will set the password as that requested by the technical contact. 1.b.ii. The technical contact will be required to change the password after the initial login. 1.b.iii. The technical contact will have a web-based interface to change the password. 1.b.iv. Password Strength

• Must be at least 8 characters. • Must contain at least one letter, one digit, and one capital letter. • Must contain at least one of the following special characters: !@#$%&*+={}?<>"' • Must share less than 3 consecutive characters with the userid. • Cannot be a password used within the past year. • Expires every 90 days.

2. Respond to Required Questions - The technical contact will supply institution approved information to each of the questions from Section 3, “Required Basic Information”. Some of this data is for informational purposes only, while other data elements will be used directly in the XML metadata.

11

Federation Operations

3. Technical Contact Submits CSR (Creates a Ticket)

3.a. The technical contact creates a certificate signing request (CSR).

3.b. The technical contact will upload this CSR using the administrative interface. This upload will occur over a standard web browser (SSL) encryption to ensure privacy and security.

3.c. Additional metadata-specific information will be provided during this step and stored in a database. This information will be required to added the newly signed request to the federation metadata.

4. Verify CSR Submission - General Administration will send an email or place a telephone call to the technical contact to verify the authenticity of the uploaded CSR.

5. General Administration Signs the CSR - Please see Section 4.2, “Certificate Signing”, for details about the signing process. The successful completion of this process will generate a certificate (CRT) for usage by the federation.

6. Push Certificate (CRT) to Metadata

6.a. General Administration will add the new CRT to the "ticket" in question using a web interface.

6.b. Adding the CRT in this manner will automatically:

i. Notify the original technical contact of its availability. At which point, the technical contact can login to the system and download the CRT for usage.

ii. Update the federation metadata to incorporate this new identity provider or service provider.

7. Verify - General Administration will validate the addition to ensure the federation metadata continues to function properly.

4. Certificate Authority Operations

The following section describes the operations around the certificate authority that General Administration will manage for the Federation.

4.1. Overview

4.1.1. Root Certificate Profile

The following profile describes the public key of the certificate authority. All CSRs will be signed by the corresponding private key; the public nature of this key is critical as users must have the ability to verify the authenticity of this public key through an alternate published source. This certificate profile will also be published on the Federation's web site for public consumption.

Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=North Carolina, L=Chapel Hill, O=UNC General Administration, CN=federation.northcarolina.edu/emailAddress=root@northcarolina.edu Validity Not Before: Mar 12 15:06:12 2008 GMT Not After : Mar 10 15:06:12 2018 GMT Subject: C=US, ST=North Carolina, L=Chapel Hill, O=UNC General Administration, CN=federation.northcarolina.edu/emailAddress=root@northcarolina.edu Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit):

12

Federation Operations

00:b1:60:92:1c:29:81:9e:8e:bc:4a:64:25:24:7a: 73:ce:75:b9:f2:62:43:31:30:f4:d1:21:ed:52:42: bf:1a:39:9d:88:cb:b2:09:92:f5:13:b8:e1:bd:bb: 35:49:df:21:de:6f:eb:40:f1:7b:d1:d7:39:14:fc: 4e:78:23:38:c4:14:d0:1a:ae:fb:68:4d:44:75:2e: aa:bb:39:65:90:82:aa:14:81:5c:1d:be:2a:fb:f7: d8:27:09:16:ee:e3:ef:4b:76:2f:49:f8:87:62:ae: 72:1f:e6:95:94:87:cb:62:06:23:a5:fc:38:42:1a: 92:fd:e9:ca:d9:c2:6e:c4:27:fa:74:db:df:d6:20: 24:f9:c5:7f:52:5c:e9:6e:dd:b6:41:c4:70:75:b3: ad:62:9b:27:4d:d7:d4:f4:a6:dd:74:0b:9e:d6:54: e6:9c:f5:35:51:27:fd:0e:d0:15:44:36:8e:89:4c: 6a:b1:fb:12:74:50:92:8b:54:0c:23:58:a1:b2:b3: 78:d2:31:73:05:34:b1:db:7e:97:20:72:66:d4:d3: b0:2f:23:d5:db:2d:27:39:27:ca:7f:02:3a:de:ed: 09:2e:b6:19:18:50:30:65:a7:bb:06:f4:41:d7:83: 80:3f:71:65:47:7b:d7:47:9a:74:af:26:0c:0f:39: 0d:79 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 70:B1:64:94:CE:F2:6E:C4:09:FF:06:46:21:73:4E:8C:2A:0F:22:2C X509v3 Authority Key Identifier: keyid:70:B1:64:94:CE:F2:6E:C4:09:FF:06:46:21:73:4E:8C:2A:0F:22:2C DirName:/C=US/ST=North Carolina/L=Chapel Hill/O=UNC General Administration /CN=federation.northcarolina.edu/emailAddress=root@northcarolina.edu serial:00 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: md5WithRSAEncryption 34:8c:85:9f:26:0c:5c:a4:87:88:af:84:7a:6e:ba:02:4a:5b: 94:4d:c3:9b:e5:67:09:78:50:65:cb:f6:cd:42:60:8f:1b:f5: 4a:c8:a3:4a:ff:b2:c9:46:48:6b:ba:33:3f:87:12:b6:f5:46: ff:87:58:38:7f:b2:cf:d7:ab:67:f1:5c:1b:d6:7c:a6:33:d2: 0d:f3:5f:a3:97:10:f8:a8:91:54:02:6b:24:e8:33:dc:4d:2f: a1:d6:6f:86:62:67:b4:f8:17:d1:46:2a:07:e1:aa:55:d8:3f: 7e:ce:87:04:41:c0:b3:4b:e8:b4:2b:4d:80:b4:86:4f:f2:8a: 78:d1:ad:10:ff:7d:33:c0:3f:31:5c:73:de:5a:92:98:70:3f: 7e:89:97:9c:20:38:09:22:87:fa:7e:e2:09:54:dd:2c:f7:2d: 0a:65:25:e5:bd:f9:84:10:b4:a1:75:5c:d0:6e:cc:5e:1c:ad: 12:63:19:c1:bf:ac:8e:00:dc:c9:25:ba:39:77:d2:59:0a:d0: d5:d7:9d:49:63:79:f5:9b:a3:ce:1d:cc:48:d9:5d:82:01:c9: 41:a9:d2:ee:82:d4:93:3d:ec:20:3a:56:96:22:a4:15:32:97: fd:f7:61:22:f6:06:39:2d:dd:fd:ec:c7:5a:23:db:0f:cc:d1: 0e:59:7d:8e

4.1.2. Credential Lifetime

All certificate signing requests (CSR) will be valid for a period of 1,095 days from the date of signature. Therefore, all participating federation members will be required to re-issue CSRs for signing every 3 years. This security measure is taken to ensure only valid identity providers and service providers are periodically claimed by their owner.

4.1.3. Security

The certificate authority has the responsibility to keep the private key truly private. The integrity of the entire Federation depends on this fact. As such, General Administration will enact the following steps to maximize the integrity of the private key and minimize the risk of exposure:

13

Federation Operations

• The private key will be removed from ALL machines accessible via the network. • The private key will be burned on a CD. • Two backup copy of this CD will be burned as well as a thumb drive (for a total of 3 backup copies) • Three copies of the private key (2 CDs and one thumb drive) will be placed in a locked safe. • The locked safe will be bolted to the floor within the machine room of the CA. • Only 3 individuals (Director of Online Service, Director of Network & Media Services, and the Senior

Systems Administrator) will have a key to the safe. • The machine room will have a coded lock known only to a small group of systems and network

administrators. • The machine room will be monitored by a camera and notification system. • The final copy of the private key will be placed in a safe deposit box at an alternate physical location (for

disaster recovery).

4.1.4. Auditing

General Administration will perform the following auditing steps to minimize the risk of CA breach:

• Unix's Logwatch will be enabled to alert systems administrators to any unexpected machine behavior. • A paper based log will be placed within the safe and the the safe opener will be required to fill out the

following information each time the safe is opened. • Name of person opening the safe. • Title of person. • Reason for opening the safe. • Materials removed from the safe. • Time safe was opened. • Materials returned to the safe. • Time safe was closed.

• The database responsible for capturing signed certificate (CRT) files will capture the userid of the individual signing the certificate as well as the time stamp of upload.

4.2. Certificate Signing

The following list represents the sequence of steps required by the CA to sign a CSR and return the newly created CRT file to the original owner.

1. The Certificate Authority Administrator (CAA) will copy the CSR from the uploaded ticket to the dedicated location on the signing machine. This CSR will reside in this location indefinitely so as to expedite recovery from a CA breach.

2. The CAA will contact one of the dedicated individuals with a key to the safe (Safe Opener - SO)

3. The SO will unlock the safe and fill out the required auditing form.

4. The SO will give the CD containing the private key to the CAA.

5. The CAA will take the CD and insert it into the CA machine.

6. The CAA will mount the CD within the operating system. During this time, only the root user may access the CD due to Unix file system permissions.

7. The CAA will proceed to sign the CSR with the CA's private key from the CD.

8. The CAA will unmount and eject the CD from the machine.

9. The CAA will return the CD to the SO.

10. The SO will return the CD to the safe and complete the corresponding audit log.

11. The SO will lock the safe.

12. Both the SO and the CAA will leave the room.

14

Federation Operations

15

13. The CAA will take the appropriate actions of incorporating the CRT into the federation metadata and sending it to the requesting institution.

4.3. Certificate Revocation

In the event that the private key of an identity or service provider is exposed, then that certificate must be revoked by the CA to minimize the risk for malicious actions resulting from the use of the breached key. However, the Federation uses explicit certificates embedded directly within the metadata. Therefore, the traditional need to maintain separate certificate revocation lists (CRL) is not required since only explicitly enumerated certificates are valid within the federation. Consequently, the procedure for revoking is greatly simplified and the security around this revocation is greatly enhanced.

1. The technical contact (TC) for the member institution creates a new private key for the identity provider or service provider in question.

2. The TC creates a certificate signing request (CSR) from this private key.

3. The TC utilizes the web-based administrative interface to upload the CSR.

4. General Administration (GA) follows the standard process (see Section 4.2, “Certificate Signing”) for generating the new CRT.

5. GA will replace the original CRT with the newly created CRT. This replacement will automatically publish the new CRT to the federation metadata, thereby, instantly revoking the original CRT.

6. GA will notify the TC and make the new CRT available for download from the administrative interface.

4.4. Recovery from CA Breach

While great lengths have been taken to avoid exposure of the CA signing key, the following section describes the operations that will occur in order to recover from this security violation. The key is consider compromised if it leaves the control of General Administration. In other words, if the physical media is separated from the secure possession of General Administration.

1. General Administration (GA) will notify both the administrative and technical contacts of each participating member via email.

2. GA will create a new certificate authority public and private key pair.

3. GA will replace the original public key in the Federation metadata with the new one. This will have the effect of revoking the certificate from the Federation since it uses explicit key enumeration.

4. The newly created key pair will be used for the following sequence of steps FOR EACH certificate signing request (CSR) that was previously signed by the federation:

4.a. Resign the CSR, from the original request (See Section 4.2, “Certificate Signing”). This has the effect of revoking the original CRT as described in Section 4.3, “Certificate Revocation”.

4.b. Update the metadata with the new CRT file.

4.c. Send the CRT to the technical contact of the member.

5. GA will securely destroy the original media that contained the private key.

6. GA will securely create new media that contains the private key.

7. GA will completely remove the private key from all networked machines.

8. GA will notify both the administrative and technical contact of each participating member via email at the conclusion of the recovery process.

16

Chapter 4. Identity Attributes

1. Overview

The Federation, purposefully, does not define an exhaustive set of identity attributes. Attribute exchange is a function of the application within the Federation, not the Federation itself. In other words, it is unreasonable for the Federation to adequately list all possible attributes needed by all applications. However, the Federation establishes standards and practices for establishing and exchanging attributes.

Federation members should take great care to not reinvent the wheel; in other words, if the attribute needed for a particular application already has an existing, widely adopted definition, then participants should use the existing standard instead of creating a custom attribute that will exist only within the scope of the application. Participants should take great care to ensure newly created attributes do not overlap with existing standards.

The remainder of this document outlines the common set of baseline attributes that each identity provider and application can use to provide distributed services to the Federation community. Again, this not an exhaustive list, but serves as a baseline of attributes that can be reliably supplied by identity providers.

Note

These attributes are designed to be consistent with the InCommon Federation to maintain consistency with other higher education institutions. See [InCommon Federation Attribute Summary] for reference.

2. Attribute Summary

The following list represents the column headings for the subsequent summary table:

Name A short name for the attribute.

Formal Name The formal name of the attribute when expressed in a SAML assertion in accordance with the [MACE-Dir SAML Attribute Profiles (PDF)].

Default HTTP Header The default HTTP header name for the attribute, as seen by most applications using Shibboleth 2 out of the box (but this can be anything).

Datatype An informal description of the value syntax of the attribute

Multi? Indicates whether the attribute is multi-valued

Table 4.1. Attribute Summary

Name Formal Name Default HTTP Header Datatype Multi?eduPersonScopedAffiliation urn:mace:dir:attribute-

def:eduPersonScopedAffiliation

HTTP_SHIB_EP_AFFILIATION

Domain-Qualified String Enumeration

Y

eduPersonPrincipalName urn:mace:dir:attribute-def:eduPersonPrincipalName

HTTP_SHIB_EP_PRINCIPALNAME

Domain-Qualified String

N

eduPersonTargetedID urn:oid:1.3.6.1.4.1.5923.1.1.1.10

HTTP_SHIB_EP_TARGETEDID

String, max. 256 characters

N

sn urn:mace:dir:attribute-def:sn

HTTP_SHIB_PERSON_SURNAME

String Y

givenName urn:mace:dir:attribute-def:givenName

HTTP_SHIB_INETORGPERSON_GIVENNAME

String Y

displayName urn:mace:dir:attribute- HTTP_SHIB_INETORG String N

Identity Attributes

17

Name Formal Name Default HTTP Header Datatype Multi?def:displayName PERSON_DISPLAYNA

ME mail urn:mace:dir:attribute-

def:mail

HTTP_SHIB_INETORGPERSON_MAIL

String Y

2.1. eduPersonScopedAffiliation

2.1.1. Description

Multiple values of the form value@domain, where domain is (typically) a DNS-like subdomain representing the organization or sub-organization of the affiliation (e.g., "northcarolina.edu") and value is one of:

• member • student • employee • faculty • staff • alum • affiliate

Note that these values are NOT case-sensitive, and capital or mixed-case values are permitted (e.g., MEMBER, Member, MeMbEr), though all lower-case is recommended.

2.1.2. Usage Notes

Affiliation is a high-level expression of the relationship of the user to the university or organization specified in the domain. A user can possess many affiliations, though some values are mutually exclusive. This attribute is often made available to any Shibboleth service provider, and is a good way to filter or block users of a given general type. In particular, "member" is an indication that the user is somebody with relatively official standing with a university at the present time, and does not apply to guests, other temporary accounts, terminated employees, unpaid/unregistered students, and other exceptional cases. For a list of valid domains please see the next section.

2.2. eduPersonPrincipalName

2.2.1. Description

A single value of the formuser@domain, where the domain is (typically) a DNS-like subdomain representing the security domain of the user (e.g., "northcarolina.edu") and user is generally a username, NetID, UserID, etc. of the sort typically assigned for authentication to network services within the security domain.

2.2.2. Usage Notes

EPPN is the eduPerson equivalent of a username. It typically has most of the properties usually associated with usernames (such as uniqueness and a naming convention of some sort), with the added property of global uniqueness through the use of a scope. An application that tracks information based on it can therefore interact with users via any number of identity providers without fear of duplicates, although the possibility for recycling/reassignment does still exist within the domain of a given identity provider. Note that at some Identity Providers a user can freely change their local account name (in the case of a name change due to marriage, for example), and the corresponding EPPN will typically change as well. This can cause a loss of service until name changes propagate throughout every application storing the value. For a less dynamic identifier, see also the eduPersonTargetedID attribute. For a list of valid domains please see the next section.

2.3. eduPersonTargetedID

2.3.1. Description

Identity Attributes

A single string value of no more than 256 characters that uniquely identifiers a user in an opaque, privacy-preserving fashion. In most cases, the value will be different for a given user for each service provider to which a value is sent, to prevent correlation of activity between service providers.

2.3.2. Usage Notes

This attribute offers a powerful alternative to the use of eduPersonPrincipalName as a user identifier within applications and databases. Its power lies in the fact that it offers a significant degree of privacy and control for users. It also tends to be more stable than EPPN because it doesn't change merely in response to superficial name changes. It still may change, but generally in a more controlled fashion. It also requires a policy of non-reassignment. That is, while a given user may be associated with more than one value over time, a single value once assigned will never be assigned to any other user. When appropriate, the value can remain consistent across multiple service providers, if those systems have a demonstrated relationship and need to share information about the user's activities. Such sharing must be tightly controlled. Note that the values are not guaranteed to be unique except within a given identity provider's set of values.

2.4. sn

Multiple string values containing components of the users' "family" name or surname. In other words, the individual's "last name" using western conventions.

2.5. givenName

Multiple string values containing the part of the user's name that is not their surname or middle name. In other words, the individual's "first name" using western conventions.

2.6. displayName

A single string value indicating the preferred name of a person to be used for display purposes, for example a greeting or a descriptive listing.

2.7. mail 2.7.1. Description

Preferred address for the "to:" field of email to be sent to this person. Usually of the form localid@univ.edu. Likely only one value.

2.7.2. Usage Notes

The address in this attribute cannot be assumed to represent an organizationally-assigned contact address for a user established as part of a strong identity-proofing process. This may be true of some organizations that assert this attribute, but some organizations may permit users to provide their own preferred address, e.g. an email account at an Internet mail service.

3. Valid Domains

For each of the scoped attributes listed above, the base of the domain must be within this list:

• appstate.edu • ecu.edu • ecsu.edu • uncfsu.edu • ncat.edu • nccu.edu • ncarts.edu (might eventually be uncsa.edu) • ncsu.edu • unca.edu • unc.edu

18

Identity Attributes

19

• uncc.edu • uncg.edu • uncp.edu • uncw.edu • wcu.edu • wssu.edu • ncssm.edu • northcarolina.edu • unctv.org

References

[] InCommon Federation: Participant Operational PracticesFebruary 2008

[] E-Authentication Guidance for Federal AgenciesApril 2004

[] NIST E-Authentication GuidanceApril 2004

[] InCommon Federation Attribute SummarySeptember 2007

[] MACE-Dir SAML Attribute Profiles (PDF)April 2006

20

Glossary

A

Access Management Systems Any system that is responsible for mapping individual identities to a set of actions for which that identity has access. In short, an access management system is the engine that determines access to a particular resources (or resources) for a set of users.

Attribute Assertion The process by which one entity asserts, in a non-repudiatable manner, that an attribute (or attributes) about an individual are accurate. This assertion is often communicated to another entity; that entity must decide if that assertion is trustworthy.

C

Certificate Authority (CA) A trusted third-party organization or company that issues digital certificates used to create digital signatures and public-private key pairs.

Certificate Revocation List (CRL) A signed list indicating a set of certificates that are no longer considered valid by the certificate issuer.

Certificate Signing Request (CSR) An unsigned certificate for submission to a Certification Authority, which signs it with its private key.

Credential Software keys and passwords as well as other security tokens, such as a proxy or smart card, are forms of credentials used on computers.

Credential Provider An entity that issues credentials to its members for the purpose of authenticating that individuals identity as well as authorizing him/her to access a particular system.

D

Discovery Service Part of the Shibboleth bundle of software that is responsible for connecting an individual user attempting to access a service, with his/her appropriate identity provider. This discovery service is able to read a federation metadata file and generate a web page to enable the user to select the appropriate identity provider.

Domain Name Service (DNS) One of the core Internet protocols and mechanisms responsible for translating human-readable names (eg "federation.northcarolina.edu") into the binary IP addresses that are actually used to move data packets around on the Internet.

E

Electronic Identifier A string of characters or structured data that may be used to reference an electronic identity. Examples include an email address, a user account name, a Kerberos principal name, a UC or campus NetID, an employee or student ID, or a PKI certificate [InCommon_POP].

Electronic Identity A set of information that is maintained about an individual, typically in campus electronic identity databases. May include roles and privileges as well as personal information. The information must be authoritative to the applications for which it will be used [InCommon_POP].

21

Glossary

22

Electronic Identity Database A structured collection of information pertaining to a given individual. Sometimes referred to as an "enterprise directory." Typically includes name, address, email address, affiliation, and electronic identifier(s). Many technologies can be used to create an identity database, for example LDAP or a set of linked relational databases [InCommon_POP].

Enterprise Resource and Planning (ERP) Software used by companies to plan and manage the basic commercial functions of their business, such as budgeting, accounting, human resources, material flows, etc

I

Identity Attribute A single piece of information associated with an electronic identity database record. Some attributes are general; others are personal. Some subset of all attributes defines a unique individual [InCommon_POP].

Identity Management System A set of standards, procedures and technologies that provide electronic credentials to individuals and maintain authoritative information about the holders of those credentials [InCommon_POP].

Identity Provider (IDP) A campus or other organization that manages and operates an identity management system and offers information about members of its community to other InCommon participants [InCommon_POP].

InCommon Federation The mission of the InCommon Federation is to create and support a common framework for trustworthy shared management of access to on-line resources in support of education and research in the United States. To achieve its mission, InCommon will facilitate development of a community-based common trust fabric sufficient to enable participants to make appropriate decisions about access control information provided to them by other participants. InCommon is intended to enable production-level end-user access to a wide variety of protected resources. InCommon uses standards-based, SAML-compliant Shibboleth® as its federating system.

L

Level of Assurance (LOA) The degree of certainty that the user has presented an identifier (a credential in this context) that refers to the user presenting it.

S

Service Provider (SP) A campus or other organization that makes on-line resources available to users based in part on information about them that it receives from other Federation participants [InCommon_POP].

Shibboleth An Internet2 project that has created an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure based on SAML

T

Trust The act of believing something to be true. In this case, the article of belief is the attribute assertion from one participating entity to another. As with any article of belief, level of confidence in this belief stems from the quality of the information and the internal processes of the asserting party.