OpenID Foundation iGov Working Group A. Cooper 3 August 2023 International Government Assurance Profile (iGov) Use Cases - draft 01 openid-igov-use-cases-1_0 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 [RFC2119]. Table of Contents 1. USG-NIST Note . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Types of eID Scheme . . . . . . . . . . . . . . . . . . . . . 2 3. Federation Models to be Considered for iGov Profile . . . . . 2 3.1. Direct RP / IDP Relationship . . . . . . . . . . . . . . 2 3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 2 3.2. Indirect Model . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Direct Relationship - Dynamic Discovery . . . . . . . . . 5 3.3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Optional (General) Use Cases . . . . . . . . . . . . . . 6 4. Claims Requirements (UserInfo) . . . . . . . . . . . . . . . 7 4.1. Mandatory UserInfo / Identity Claims . . . . . . . . . . 7 4.2. Optional UserInfo / Identity Claims . . . . . . . . . . . 8 4.3. Privacy Use Cases . . . . . . . . . . . . . . . . . . . . 9 4.4. The Need to Support Identity Matching . . . . . . . . . . 9 5. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 9 6. Technical Requirements . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . 11 Appendix C. Document History . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Cooper Standards Track [Page 1] iGov Use Cases August 2023 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 Case | Description | +================+=================================================+ | The user | The user selects an identity provider as | | selects an IDP | presented by the RP (the method of presentation | | for sign-in at | is implementation specific). The RP must | Cooper Standards Track [Page 2] iGov Use Cases August 2023 | the RP | 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 | This is a special case of "user selects an IDP | | IDP for sign- | for sign-in" where the RP has prior knowledge | | in (without | of the requirements for authentication e.g. | | user | only a specific identity provider meets the | | intervention) | requirements for authentication such as level | | | of assurance. | +----------------+-------------------------------------------------+ | The user | The user provides relevant credentials to the | | authenticates | IDP to facilitate sign-in (i.e. those issued | | at the IDP | 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 | TBD | | requests the | | | user consent | | | to the release | | | of attributes | | | requested by | | | the RP | | +----------------+-------------------------------------------------+ | The IDP send | The IDP must either assert an ID Token to the | | an assertion | RP or an error status as described in the | | to the RP | profile. | +----------------+-------------------------------------------------+ | The RP | The RP must be able to consume an ID Token from | | consumes the | an IDP and to check the integrity of that token | | information in | as prescribed in the profile. The RP must also | | the identity | retrieve claims for the individual referred to | | assertion to | by the ID Token (i.e. from the UserInfo | | determine if | Endpoint). The RP is then responsible for | | access to the | matching the claims in the response to the | | service should | known 'accounts' held within its systems. In | | be granted. | the case of a positive match this should result | | | in the identification of a local identifier | | | (relevant to the RP) for the user. | +----------------+-------------------------------------------------+ Cooper Standards Track [Page 3] iGov Use Cases August 2023 Table 1: Use Cases 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 Case | Description | +================+=================================================+ | The RP | The RP sends an authentication request to the | | requests | Broker, including requested attributes and any | | authentication | specific authentication requirements. | | from the | | | Broker | | +----------------+-------------------------------------------------+ | The user | The user selects an identity provider as | | selects an IDP | presented by the Broker (the method of | | for sign-in at | presentation is implementation specific). | | the Broker | | +----------------+-------------------------------------------------+ | The Broker | The Broker must generate an authentication | | requests | request to send to the IDP and send this | | authentication | request in accordance with the messaging | | from the | requirements of the relevant profile. This | | (chosen) IDP | request must mirror any specific requirement of | | | the RP as indicated in the RP authentication | | | request. | +----------------+-------------------------------------------------+ | The user | The user provides relevant credentials to the | | authenticates | IDP to facilitate sign-in (i.e. those issued | | at the IDP | 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 | Cooper Standards Track [Page 4] iGov Use Cases August 2023 | | by the scheme rules for the federation. | +----------------+-------------------------------------------------+ | The IDP | TBD | | requests the | | | user consent | | | to the release | | | of attributes | | | requested by | | | the RP | | +----------------+-------------------------------------------------+ | The IDP send | The IDP must either assert an ID Token to the | | an assertion | Broker or an error status as described in the | | to the RP | profile. | +----------------+-------------------------------------------------+ | The Broker | The Broker should relay the IDP assertion (ID | | relays the | Token) to the RP in response to the originating | | assertion to | RP authentication request. | | the RP | | +----------------+-------------------------------------------------+ | The RP | The RP must be able to consume an ID Token from | | consumes the | an IDP and to check the integrity of that token | | information in | as prescribed in the profile. The RP may also | | the identity | retrieve claims for the individual referred to | | assertion to | by the ID Token and / or perform matching (see | | determine if | optional use cases below). | | access to the | | | service should | | | be granted. | | +----------------+-------------------------------------------------+ Table 2: Use Cases 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. Cooper Standards Track [Page 5] iGov Use Cases August 2023 3.3.1. Use Cases +===============+==================================================+ | Use Case | Description | +===============+==================================================+ | Agency1 user | Typically, the user from Agency1 only conducts | | accesses an | day-to-day business within her agency. This is | | RP at Agency2 | the first attemt to perform a job function at an | | | application hosted by another agency - Agency2 | +---------------+--------------------------------------------------+ | Agency1, as | Agency2 initiates a discovery process to | | an IDP, is | determine the IDP the user is associated with. | | unknown to | This is perhaps a closed community, so Agency1 | | Agency2 | is trusted. | +---------------+--------------------------------------------------+ | The user | The user provides relevant credentials to the | | authenticates | IDP to facilitate sign-in (i.e. those issued | | at Agency1 | 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. | +---------------+--------------------------------------------------+ Table 3: Use Cases 3.4. Optional (General) Use Cases +=================+===============================================+ | Use Case | Description | +=================+===============================================+ | The RP performs | The RP may also retrieve claims for the | | matching to | individual referred to by the ID Token (i.e. | | identify a | from the UserInfo Endpoint). The RP is then | | local | responsible for matching the claims in the | | identifier or | response to the known 'accounts' held within | | account for the | its systems. In the case of a positive match | | user | this should result in the identification of a | | | local identifier (relevant to the RP) for the | | | user (see Claims Requirements below). | +-----------------+-----------------------------------------------+ | RP requests | Support for domain specific attributes | | additional | (claims) is of great importance to EU member | Cooper Standards Track [Page 6] iGov Use Cases August 2023 | attributes | states. An outline of how this could be | | during | implemented should be included in the | | authentication | profile. | | request | | +-----------------+-----------------------------------------------+ | RP specifies a | The RP specifies requirements for | | level of | authentication in particular the required | | assurance when | level of assurance acceptable for sign-in to | | requesting | the service. | | authentication | | +-----------------+-----------------------------------------------+ | The IDP asserts | Transaction monitoring and authentication | | transaction | context information may be of great | | monitoring and | importance to protect the RP (service) from | | / or additional | attack or alert the RP to potential fraud. | | authentication | | | context | | | information | | | alongside | | | identity | | | assertion | | +-----------------+-----------------------------------------------+ Table 4: Use Cases 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 +===================+=======================================+ | 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 | +-------------------+---------------------------------------+ Cooper Standards Track [Page 7] iGov Use Cases August 2023 | 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) | +-------------------+---------------------------------------+ Table 5: Mandatory UserInfo / Identity Claims at assurance level XXX??? 4.2. 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. | +----------------+---------------------------------------------+ Table 6: Optional UserInfo / Identity Claims Cooper Standards Track [Page 8] iGov Use Cases August 2023 4.3. 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 | Need to encourage partial attribute values, | | vs Attribute | or boolean responses, not complete values. | | Values | For example, 'over 21=true', not '3/13/1980' | +------------------+----------------------------------------------+ Table 7: Privacy Use Cases 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. Cooper Standards Track [Page 9] iGov Use Cases August 2023 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 | +--------------------------------------------+ Table 8: NIST Levels of Assurance 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 | +----------------------------------------+ Table 9: eIDAS Levels of Assurance 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. Cooper Standards Track [Page 10] iGov Use Cases August 2023 +=================+============================================+ | Requirement | Description | +=================+============================================+ | Message | Method of proving the integrity of a | | Integrity | 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 | Method of preventing the interception and | | Confidentiality | 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 | Prevent the replay of authentication | | Protection | 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. | +-----------------+--------------------------------------------+ Table 10: HTTP Response Headers and Values 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Appendix A. Acknowledgements The OpenID Community would like to thank the following people for their contributions to this specification: Michael B. Jones. Appendix B. Notices 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 Cooper Standards Track [Page 11] iGov Use Cases August 2023 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 -01 * Enable building with https://author-tools.ietf.org/. * Applied OpenID specification conventions. -2016-04-06 * Initial document import -2016-09-06 * Fix some xlm2rfc formatting Cooper Standards Track [Page 12] iGov Use Cases August 2023 Author's Address Adam Cooper Cooper Standards Track [Page 13]