| iGov Use Cases | August 2023 | |
| Cooper | Standards Track | [Page] |
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 [RFC2119].¶
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.¶
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.¶
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.¶
| 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 | TBD |
| 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. |
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.¶
| 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 | TBD |
| 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). |
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.¶
| 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. |
| 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. |
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.¶
| 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) |
| Claim | Description |
|---|---|
| address | Free format address data base64 encoded |
| postal_code | Postal code of the individual's current address where available |
| 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. |
| 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' |
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).¶
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 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 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.¶
Technical considerations for the messaging flow to protect the consuming services and individual users from attack.¶
| 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. |
The OpenID Community would like to thank the following people for their contributions to this specification: Michael B. Jones.¶
Copyright (c) 2023 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.¶
-01¶
-2016-04-06¶
-2016-09-06¶