| gain-poc-oidc4ida-profile-1_0 | February 2024 | |
| Lodderstedt & Fett | Standards Track | [Page] |
This document defines a profile of OpenID Connect for Identity Assurance [OpenID4IDA] for the purpose of the GAIN Proof of Concept.¶
The GAIN PoC aims at evaluating and demonstrating the technical feasibilty of the vision described in the GAIN whitepaper [GAIN-WP]. This document defines the technical
interface exposed by IIPs to RPs for the purpose of requesting and receiving assured identity data in the form of verified claims. This interface is a profile of
the OpenID Connect for Identity Assurance specification. It defines the subset of syntactical elements of verified_claims and end-user claims that every compliant
IIP MUST implement. It also defines the security profile, especially client authentication method, that MUST be utilized by all compliant implementations.¶
The GAIN PoC uses the technical standard OpenID Connect 4 Identity Assurance [OpenID4IDA] for the interface between identity providers and relying parties. This standard supports transfer of user claims along with metadata about identity assurance levels and trust frameworks. It can be used for integration of "traditional" identity providers but also for wallets and provides an interoperable, easy to integrate interface.¶
All IIPs MUST at least support the following user claims:¶
NOTE: IIPs MAY support further end-user claims, however there is no guarentee for a RPs that all IIPs will support more then the end-user claims listed above.¶
End-user claims are requested by the RP using the claims as defined in Section 5.5. of [OpenID] and the verified_claims element as defined in [OpenID4IDA]. The RP MUST at least request attestation of a trust_framework element along with the end-user claims.¶
This is a non-normative example request:¶
{
"id_token":{
"verified_claims":{
"verification":{
"trust_framework":null
},
"claims":{
"given_name":null,
"family_name":null,
"birthdate":null
}
}
}
}
claims parameter in an OpenID Connect Request
The IIP MUST provid the end-user claims within a verified_claims container along with at least a trust_framework element as defined in [OpenID4IDA]. The trust framework of the particular IIP is conveyed in the trust_framework element value. The actual end user claims are provided in the claims container.¶
This is an example of an ID token issued by an IIP.¶
{
"iss": "https://issuer.example.com",
"sub": "248289761001",
"verified_claims": {
"verification": {
"trust_framework": "example_trust_framework"
},
"claims": {
"given_name": "Max",
"family_name": "Meier",
"birthdate": "1956-01-28"
}
}
}
NOTE: Every IIP determines the trust framwork it asserts in the verified claims object. RPs use the trust framework to determine how the end user claims were obtained and maintained and whether that is compatible with their requirements.¶
OpenID Connect 4 Identity Assurance is used in conjunction with the authorization code grant type as defined in Section 3.1. of [OpenID].¶
This profile utilizes certificates for RP authentication and access token replay prevention. RPs authenticate towards IDPs using self-signed X.509 certificates and TLS Client Authentication as defined in [RFC8705]. The access tokens issued in this flow MUST be bound to the RP's certificate used to authenticate the client at the respective IIP’s token endpoint (sender constraint access tokens). The IIP must enforce this binding on the userinfo endpoint.¶
This specification is based on the work conducted in the GAIN "Alpha PoC" before the OpenID Foundation's GAIN PoC community group was established. The following people contributed to the the initial draft of this profile: Anil Mahalaha, Daniele Citterio, Dima Postnikov, Erik Lupander, Carl Hoessner, Joseph Heenan, Andrea Roeck, Fransceso Vetrano, Maciej Machaluk, Mike Varley.¶
We would also like to thank ... for their valuable feedback and contributions that helped to evolve this specification.¶
Copyright (c) 2022 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.¶
-00 (Initial draft of the specification document)¶