OpenID 2.0

Profile

Ayesha KanwalMS-CCS-42011-NUST-MS-CCS-10

OpenID 2.0

Profile

Background

0 U.S. federal government initiative to merge the management of digital identities, credentials and access control into one comprehensive management approach.

0 Office of Management and Budget (OMB) issued E-Authentication Guidance for Federal Agencies.

Level 1 Level 2 Level 3 Level 4

0 General Services Administration’s (GSA) Office of Government wide Policy (OGP) is responsible for government-wide coordination and oversight of Federal Identity, Credential, and Access Management (ICAM).

0 ICAM Identity Scheme Adoption Process includes the assessment of scheme for compliance with [NIST SP 800-63] and other privacy and security requirements.

OpenID Overview0 It facilitate Portable identity through the most open set of

specifications and technologies possible.

0 The OpenID Authentication 2.0 specification is the core of the OpenID protocol.

0 The usual portable identity model includes three main actors: User, Identity provider and Relaying party

OpenID 2.0 Adopted by ICAM

0 OpenID 2.0 has completed the scheme adoption process and has been adopted by ICAM for the purpose of Level of Assurance (LOA) 1 identity authentication (i.e., conducting low risk transactions with the Federal government).

Use Case 1

Use Case 2

Features

0 Single Sign-On

0 Reduced Sign-on

0 Session Reset

0 Attribute Exchange

0 Authentication Policy

0 Pseudonymous Identifiers

Security

0 SSL/TLS is used to positively identify one another during all direct communication ( IdP & RP).

0 The RP verifies that the IdP is an ICAM-authorized LOA 1 IdP.

0 An RP and IdP establish a Hash Message Authentication Code (HMAC) secret and a reference to the HMAC called an Association Handle.

1) Digital signature 2) Request/response Verification

End User Activation

0 The first time an end user authenticates to an RP via assertion, the RP must perform end user activation.

0 End user activation is the process an RP uses to associate a new or existing local identity record with the end user's identifier from the IdP.

1) Existing Account Linking 2) New Account Provisioning

High-level Programmed Trust Process Flow

TECHNICAL PROFILE

Federal ICAM

Profile for the

OpenID 2.0

specification

Directed Identity

0 End users MUST select an ICAM-approved Identity Provider (IdP) from a list provided by the Relying Party (RP).

0 The RP MUST only discover the OpenID Provider (OP) Identifier Element for initial discovery.

Association Handles

0 The RP SHOULD request an association type of HMAC-SHA256.

0 The IdP SHALL set the expires_in value for an association.

0 The IdP SHALL NOT reuse the HMAC secret across association handles.

0 To avoid association poisoning the OP Endpoint Uniform Resource Locator (URL) is used.

Provider Authentication Policy Extension (PAPE) Request

0 IdP MUST generate a pseudonymous identifier for the end user http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

0 IdP is an ICAM-authorized LOA 1 IdP http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf

0 the IdP MUST NOT include any PII in the response http://www.idmanagement.gov/documents/no-pii.pdf

Positive Assertion Formulation

0PAPE Response

0Private Personal Identifiers

0Simple Registration and Attribute Exchange

PAPE Response

0 A positive assertion MUST contain a PAPE 1.0 response that addresses the requested PAPE 1.0 authentication policies

Private Personal Identifiers

0 The pseudonym is used to identify the end user to the RP in a way that protects the end user's privacy by preventing propagation of the end user's common identifier throughout the Federal Government.

0 This Private Personal Identifier (PPID) SHALL be expressed in both the openid.identity and openid.claimed_identity fields within positive assertions about the end user.

0 The IdP MUST construct a pseudonym in a way that ensures that it cannot be reverse engineered to help identify an end user across multiple realms.

Simple Registration and Attribute Exchange

0 The assertion MUST NOT include any end user PII (i.e., AX and SREG) unless the RP specifically requests the attribute(s).

0 The IdP MAY implement a mechanism for the end user to opt in to always sending the listed attributes to the specific RP for subsequent transactions.

Positive assertion verification

0 The RP MUST verify that all of the following fields are included in the IdP signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity.

0 The RP MUST check the openid.response_nonce and return_to.

Unsolicited Positive Assertions

0 RP MAY accept the unsolicited response if it is an ICAM-authorized LOA 1 IdP.

0 The RP MUST reject an unsolicited assertion that does not contain the following PAPE 1.0 authentication policies

0 The RP MUST reject an unsolicited assertion if it contains PII that it would not otherwise request or is not authorized to accept.

Relying Party Discovery

0 The RP MUST publish an eXtensible Resource Descriptor Sequence (XRDS) discovery document.

0 The IdP MUST perform RP discovery and return_to validation.

Thank you