A. Cooper
April 6, 2016

International Government Assurance Profile (iGov)
igov-profile-draft-00

Abstract

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


Table of Contents

1. USG-NIST Note

Should we separate authentication from claims here? Each use case discussion assertions of identity data, then userinfo for claims. Should we exclude claims from authentication requests? In addition, phase 1 of the iGov work will not be to support exotic privacy requirements, but shouldn't we have use cases for them? Typically identity claims in idToken and attributes in userinfo endpoint. Many optimize with attributes coming back in IDToken. Fix indirect to be proxy/hub. Broker is more of a biz model then a technology.

2. Types of eID Scheme

The eID schemes used for access to government systems varies considerably between nations and can be crudely categorised by the origin of eID issuance (e.g. public or private sector), and the model of eID federation (direct or indirect model, for example, a broker or hub). Overlaid are the legal requirements for eID largely derived from more general law such as Data Protection / Privacy regulations and acts under national and / or international law. There are some specific eID laws although the most widespread currently is the eIDAS Regulation applying to all 28 EU Member States. These variances should be reflected in the flexibility of the iGov profile in order to support the widest possible range of government eID solutions.

3. Federation Models to be Considered for iGov Profile

3.1. Direct RP / IDP Relationship

In this model the RP and IDP(s) are known to each other directly and the user is able to select and IDP (where multiple choices are available) directly when interacting with the RP service. This is often the case where there are a small number of national eID IDPs and those providers are relatively static.

This model assumes that the Relying Party and the Identity Provider have a direct relationship and do not require a broker or federation hub to route authentication requests.

3.1.1. Use Cases

Use Cases
Use Case Description
The user selects an IDP for sign-in at the RP The user selects an identity provider as presented by the RP (the method of presentation is implementation specific). The RP must generate an authentication request to send to the IDP, to include requested attributes, if any, and send this request in accordance with the messaging requirements of the relevant profile.
RP selects an IDP for sign-in (without user intervention) This is a special case of “user selects an IDP for sign-in” where the RP has prior knowledge of the requirements for authentication e.g. only a specific identity provider meets the requirements for authentication such as level of assurance.
The user authenticates at the IDP The user provides relevant credentials to the IDP to facilitate sign-in (i.e. those issued following a successful registration process with the IDP). The IDP must provide a status code describing the nature of any failure to the RP when the authentication is not successful at the IDP. This may be the result of a user cancel action, failure to authenticate, or other error state as described by the scheme rules for the federation.
The IDP requests the user consent to the release of attributes requested by the RP The IDP send an assertion to the RP
The IDP must either assert an ID Token to the RP or an error status as described in the profile. The RP consumes the information in the identity assertion to determine if access to the service should be granted.
The RP must be able to consume an ID Token from an IDP and to check the integrity of that token as prescribed in the profile. The RP must also retrieve claims for the individual referred to by the ID Token (i.e. from the UserInfo Endpoint). The RP is then responsible for matching the claims in the response to the known ‘accounts’ held within its systems. In the case of a positive match this should result in the identification of a local identifier (relevant to the RP) for the user.

3.2. Indirect Model

There are a variety of examples nationally where an identity broker or federation hub has been deployed, such as the UK, Sweden and Denmark as well the US (Connect.Gov). It is clear that this model will persist and that other nations are considering the implementation of similar models.

In this case a Broker or Federation Hub is used to route requests for authentication from Relying Parties to the required Identity Provider. The method used to choose an identity provider is implementation specific and can be user and/or Relying Party driven.

3.2.1. Use Cases

Use Cases
Use Case Description
The RP requests authentication from the Broker The RP sends an authentication request to the Broker, including requested attributes and any specific authentication requirements.
The user selects an IDP for sign-in at the Broker The user selects an identity provider as presented by the Broker (the method of presentation is implementation specific).
The Broker requests authentication from the (chosen) IDP The Broker must generate an authentication request to send to the IDP and send this request in accordance with the messaging requirements of the relevant profile. This request must mirror any specific requirement of the RP as indicated in the RP authentication request.
The user authenticates at the IDP The user provides relevant credentials to the IDP to facilitate sign-in (i.e. those issued following a successful registration process with the IDP). The IDP must provide a status code describing the nature of any failure to the RP when the authentication is not successful at the IDP. This may be the result of a user cancel action, failure to authenticate, or other error state as described by the scheme rules for the federation.
The IDP requests the user consent to the release of attributes requested by the RP The IDP send an assertion to the RP
The IDP must either assert an ID Token to the Broker or an error status as described in the profile. The Broker relays the assertion to the RP
The Broker should relay the IDP assertion (ID Token) to the RP in response to the originating RP authentication request. The RP consumes the information in the identity assertion to determine if access to the service should be granted.
The RP must be able to consume an ID Token from an IDP and to check the integrity of that token as prescribed in the profile. The RP may also retrieve claims for the individual referred to by the ID Token and / or perform matching (see optional use cases below).

3.3. Direct Relationship - Dynamic Discovery

This is primarily a gov-to-gov use case, promoting federated identity to promote home agency credential reuse at other agencies.

In the USG, the PIV card was intended to be usable at all agencies. For example, a NIST employee could use her card at GSA for both logical and physical access, all based on interoperable PKI. This has not really materialized, and USG is discovering that other non-PIV, non-PKI credentials have utility for a broad range of users that will never get a PIV. This use case promote the original intent of HSPD-12 and PIV - issue once, use everywhere.

3.3.1. Use Cases

Use Cases
Use Case Description
Agency1 user accesses an RP at Agency2 Typically, the user from Agency1 only conducts day-to-day business within her agency. This is the first attemt to perform a job function at an application hosted by another agency - Agency2
Agency1, as an IDP, is unknown to Agency2 Agency2 initiates a discovery process to determine the IDP the user is associated with. This is perhaps a closed community, so Agency1 is trusted.
The user authenticates at Agency1 The user provides relevant credentials to the IDP to facilitate sign-in (i.e. those issued following a successful registration process with the IDP). The IDP must provide a status code describing the nature of any failure to the RP when the authentication is not successful at the IDP. This may be the result of a user cancel action, failure to authenticate, or other error state as described by the scheme rules for the federation. At this point, Agency1 is "permanently" known to Agency2. Normal flow from other use case continues.

3.4. Optional (General) Use Cases

Use Cases
Use Case Description
The RP performs matching to identify a local identifier or account for the user The RP may also retrieve claims for the individual referred to by the ID Token (i.e. from the UserInfo Endpoint). The RP is then responsible for matching the claims in the response to the known ‘accounts’ held within its systems. In the case of a positive match this should result in the identification of a local identifier (relevant to the RP) for the user (see Claims Requirements below).
RP requests additional attributes during authentication request Support for domain specific attributes (claims) is of great importance to EU member states. An outline of how this could be implemented should be included in the profile.
RP specifies a level of assurance when requesting authentication The RP specifies requirements for authentication in particular the required level of assurance acceptable for sign-in to the service.
The IDP asserts transaction monitoring and / or additional authentication context information alongside identity assertion Transaction monitoring and authentication context information may be of great importance to protect the RP (service) from attack or alert the RP to potential fraud.

4. Claims Requirements (UserInfo)

In the interests of data minimisation balanced with the requirement to successfully identify the individual signing in to a service, claims have been split into mandatory and optional user info (identity) claims. It is expected that these claims would be made available via a UserInfo endpoint.

4.1. Mandatory UserInfo / Identity Claims

Mandatory UserInfo / Identity Claims at assurance level XXX???
Claim Description
unique_identifier This uniquely identifies the identity asserted in the country of origin but does not necessarily reveal any discernible correspondence with the subject's actual identifier (for example, username, fiscal number etc)
given_name The current given name / forename of the individual
family_name The current family name (surname) of the individual
middle_name Any middle name(s) associated with the individual
birthdate Date of Birth includes a date using the following format: YYYY + “-“ + MM + “-“ + DD (as defined for xsd:date)

4.2. Optional UserInfo / Identity Claims

Optional UserInfo / Identity Claims
Claim Description
address Free format address data base64 encoded
postal_code Postal code of the individual’s current address where available
email Current and active email address of the subject
email_verified Verified email address (see email above)
gender Gender of the individual where the identity provider has gained consent. Values for Gender attributes MUST be one of the following: · Male · Female · Not Specified
birth_place Place of birth as recorded on official documentation such as passport or birth certificate.

4.3. Privacy Use Cases

Privacy Use Cases
Use Case Description
Triple Blind No participant in the federation has access to user claims except the user, identity provider, and RP (based on user consent)
Attribute Claims vs Attribute Values Need to encourage partial attribute values, or boolean responses, not complete values. For example, 'over 21=true', not '3/13/1980'

4.4. The Need to Support Identity Matching

Matching of the identity assertion based on claims to a local identifier or ‘account’ related to the individual identity at a level of assurance is a requirement where the government in question is not able to provide a single identifier for all citizens based on an authoritative register of citizens.

The requirement for matching is also of importance where a cross-border or cross-jurisdiction authentication is required and therefore the availability of a single identifier (e.g. social security number) cannot be guaranteed for the individual wishing to authenticate.

In general, matching an asserted set of claims for an identity to relying party held records for know individuals requires a minimum set of data elements to be provided. Research in the UK and across the EU under the eIDAS Regulation has identified the minimum set of citizen attributes required to affect a successful match. Due to regional and national law this set of attribute may vary although the key elements are: name, date of birth, current address (including postal code), gender (were consent given).

5. Levels of Assurance

Identity Providers must include an Authentication Context describing the level of assurance achieved for the asserted identity. These values will be described as URIs in the same format as the SAML Authentication Context Class Reference construct.

It is recommended that both FICAM and eIDAS URI's are supported in the authentication context by default.

Current OMB Levels of Assurance (note that LOA2 will be removed soon):

NIST Levels of Assurance
NIST LoA
http://idmanagement.gov/ns/assurance/loa/1
http://idmanagement.gov/ns/assurance/loa/2
http://idmanagement.gov/ns/assurance/loa/3
http://idmanagement.gov/ns/assurance/loa/4

Current eIDAS Levels of Assurance:

eIDAS Levels of Assurance
eIDAS LoA
http://eidas.europa.eu/LoA/low
http://eidas.europa.eu/LoA/substantial
http://eidas.europa.eu/LoA/high

There is no requirement for authentication methods to be described in the Authentication Context as standards for levels of assurance should be outcome based. This also removes the requirement for RPs and IDPs to have a shared understanding of the authentication method values.

6. Technical Requirements

Technical considerations for the messaging flow to protect the consuming services and individual users from attack.

HTTP Response Headers and Values
Requirement Description
Message Integrity Method of proving the integrity of a message often accomplished through the addition of a digital signature to the response message or a specific element of the payload such as claims.
Message Confidentiality Method of preventing the interception and reading of messages in transit either at the user agent (e.g. browser) or in transit between trusted ‘nodes’ in the federation such as RP, SP and Broker (Hub).
Replay Protection Prevent the replay of authentication requests and responses. For example, SSL encryption when sending messages between entities specifically to prevent the interception and replay of claims. Consider the use of a digital signature mechanism to sign messages as well as setting a validity period for the message.

7. Normative References

[BCP195] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.
[I-D.ietf-oauth-pop-architecture] Hunt, P., Richer, J., Mills, W., Mishra, P. and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Internet-Draft draft-ietf-oauth-pop-architecture-08, July 2016.
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0", August 2015.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M. and E. Jay, "OpenID Connect Discovery 1.0", August 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M. and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013.
[RFC7009] Lodderstedt, T., Dronia, S. and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013.
[RFC7033] Jones, P., Salgueiro, G., Jones, M. and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014.
[RFC7515] Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015.
[RFC7519] Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015.
[RFC7523] Jones, M., Campbell, B. and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015.
[RFC7591] Richer, J., Jones, M., Bradley, J., Machulak, M. and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015.
[RFC7662] Richer, J., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015.

Appendix A. Acknowledgements

The OpenID Community would like to thank the following people for their contributions to this specification:

Appendix B. Notices

Copyright (c) 2015 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

Appendix C. Document History

-2016-04-06

-2016-09-06

Author's Address

Adam Cooper