openid-ida-verified-claims-1_0 | October 2024 | |
Lodderstedt, et al. | Standards Track | [Page] |
This specification defines a payload schema that can be used to describe a wide variety of identity assurance metadata about a number of claims that have been assessed as meeting a given assurance level.¶
It is intended that this payload schema is re-usable across many different contexts and application layer protocols including but not limited to [OpenID] and [W3C_VCDM].¶
This document defines a new claim relating to the identity assurance of a natural person called "verified_claims". This was originally developed within earlier drafts of OpenID Connect for Identity Assurance. The work and the preceding drafts are the work of the eKYC and Identity Assurance working group of the OpenID Foundation.¶
The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. As a non-profit international standardizing body, it is comprised by over 160 participating entities (workgroup participant). The work of preparing implementer drafts and final international standards is carried out through OIDF workgroups in accordance with the OpenID Process. Participants interested in a subject for which a workgroup has been established have the right to be represented in that workgroup. International organizations, governmental and non-governmental, in liaison with OIDF, also take part in the work. OIDF collaborates closely with other standardizing bodies in the related fields.¶
Final drafts adopted by the Workgroup through consensus are circulated publicly for the public review for 60 days and for the OIDF members for voting. Publication as an OIDF Standard requires approval by at least 50% of the members casting a vote. There is a possibility that some of the elements of this document may be subject to patent rights. OIDF shall not be held responsible for identifying any or all such patent rights.¶
This specification defines a schema for describing assured identity claims and a range of associated identity assurance metadata. Much of this definition will be optional as it depends on which processes were run, and the operational requirements for data-minimization, which elements of the JSON schema described in this document will be needed for a specific transaction.¶
This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.¶
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.¶
The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.¶
This specification defines the schema of JSON objects used to describe identity assurance relating to a natural person. It consists of the definition of a new claim called verified_claims
that will be registered with the IANA "JSON Web Token Claims Registry" established by [RFC7519]. As part of the definition of the verified_claims
claim there is also be an element defined called verification
that provides a flexible container for identity assurance metadata. It is anticipated that the verification
element may be used by other spec authors and implementers where the verification metadata is needed independently of the end-user verified claims.¶
See section 6 for normative references.¶
For the purposes of this document, the following terms and definitions apply.¶
server that can return claims and verified claims about an entity¶
Note 1 to entry : A claim provider could be an OpenID Connect provider, a verifiable claim issuer or other application component that provides verified claims.¶
[SOURCE: [OpenID], 1.2, modified - added requirement to return verified claims]¶
application that receives claims from the claim provider¶
process in which an end-user provides evidence to a provider reliably identifying themselves, thereby allowing the provider to assert that identification at a useful assurance level.¶
process conducted by the provider to verify the end-user's identity.¶
process in which the provider asserts identity data of a certain end-user with a certain assurance towards another consuming entity (such as a relying party or verifier as described in [W3C_VCDM]), typically expressed by way of an assurance level¶
Note 1 to entry: Depending on legal requirements, the provider can be required to provide evidence of the identity verification process to the consuming entity.¶
claims about an end-user, typically a natural person, whose binding to a particular end-user account was verified in the course of an identity verification process.¶
The specified JSON structures defined in this document should be usable by any protocol that needs to pass assured digital identity attributes or needs to transfer identity assurance metadata between systems using the [JSON] Data Interchange Format.¶
This specification defines a generic mechanism to add verified claims to JSON-based assertions. It uses a container element, called verified_claims
, to provide the claim recipient with a set of claims along with the respective metadata and verification evidence related to the verification of these claims. This way, claim recipients cannot mix up verified claims and unverified claims and accidentally process unverified claims as verified claims.¶
The following example would assert to the claim recipient that the claim provider has verified the claims provided (given_name
and family_name
) according to an example trust framework trust_framework_example
:¶
{ "verified_claims": { "verification": { "trust_framework": "trust_framework_example" }, "claims": { "given_name": "Max", "family_name": "Meier" } } }¶
The normative definition is given in the following.¶
verified_claims
: A single object or an array of objects, each object comprising the following sub-elements:¶
claims
: Required. Object that is the container for the verified claims about the end-user.¶
verification
: Required. Object that contains data about the verification process.¶
Note: Implementations shall ignore any sub-element not defined in this specification or extensions of this specification. Extensions to this specification that specify additional sub-elements under the verified_claims
element may be created by the OpenID Foundation, ecosystem or scheme operators or indeed singular implementers using this specification.¶
A machine-readable syntax definition of verified_claims
is given as JSON schema in [verified_claims.json], it can be used to automatically validate JSON documents containing a verified_claims
element. The provided JSON schema files are a non-normative implementation of this specification and any discrepancies that exist are either implementation bugs or interpretations.¶
Extensions of this specification, including trust framework definitions, can define further constraints on the data structure.¶
The claims
element contains the claims about the end-user which were verified by the process and according to the policies determined by the corresponding verification
element described in the next section.¶
The claims
element may contain any of the following claims as defined in section 5.1 of the OpenID Connect specification [OpenID]¶
and the claims defined in [OpenID4IDAClaims].¶
The claims
element may also contain other claims provided the value of the respective claim was verified in the verification process represented by the sibling verification
element.¶
Claim names may be annotated with language tags as specified in section 5.2 of the OpenID Connect specification [OpenID].¶
The claims
element may be empty, to support use cases where verification is required but no claims data needs to be shared.¶
This element contains the information about the process conducted to verify a person's identity and bind the respective person data to a user account.¶
The verification
element can be used independently of OpenID Connect and OpenID Connect for Identity Assurance where there is a need for representation of identity assurance metadata in a different application protocol or digital identity data format such as [W3C_VCDM].¶
The verification
element consists of the following elements:¶
trust_framework
: Required. String determining the trust framework governing the identity verification process of the claim provider.
An example value is eidas
, which denotes a notified eID system under eIDAS [eIDAS].¶
Claim recipients should ignore verified_claims
claims containing a trust framework identifier they do not understand.¶
The trust_framework
value determines what further data is provided to the claim recipient in the verification
element. A notified eID system under eIDAS, for example, would not need to provide any further data whereas a claim provider not governed by eIDAS would need to provide verification evidence in order to allow the claim recipient to fulfill its legal obligations. An example of the latter is a claim provider acting under the German anti-money laundering law (de_aml
).¶
assurance_level
: Optional. String determining the assurance level associated with the end-user claims in the respective verified_claims
. The value range depends on the respective trust_framework
value. For example, the trust framework eidas
can have the identity assurance levels low
, substantial
and high
. For information on predefined trust framework and assurance level values see [predefined_values_page].¶
assurance_process
: Optional. JSON object representing the assurance process that was followed. This reflects how the evidence meets the requirements of the trust_framework
and assurance_level
. The factual record of the evidence and the procedures followed are recorded in the evidence
element; this element is used to cross reference the evidence
to the assurance_process
followed. This has one or more of the following sub-elements:¶
policy
: Optional. String representing the standard or policy that was followed.¶
procedure
: Optional. String representing a specific procedure from the policy
that was followed.¶
assurance_details
: Optional. JSON array denoting the details about how the evidence complies with the policy
. When present this array shall have at least one member. Each member can have the following sub-elements:¶
assurance_type
: Optional. String denoting which part of the assurance_process
the evidence fulfills.¶
assurance_classification
: Optional. String reflecting how the evidence
has been classified or measured as required by the trust_framework
.¶
evidence_ref
: Optional. JSON array of the evidence being referred to. When present this array shall have at least one member.¶
check_id
: Required. Identifier referring to the check_id
key used in the check_details
element of members of the evidence
array. The claim provider shall ensure that check_id
is present in the check_details
when evidence_ref
element is used.¶
evidence_metadata
: Optional. Object indicating any metadata about the evidence
that is required by the assurance_process
in order to demonstrate compliance with the trust_framework
. It has the following sub-elements:¶
evidence_classification
: Optional. String indicating how the process demonstrated by the check_details
for the evidence
is classified by the assurance_process
in order to demonstrate compliance with the trust_framework
.¶
time
: Optional. Time stamp in ISO 8601 [ISO8601] YYYY-MM-DDThh:mm[:ss]TZD
format representing the date and time when the identity verification process took place. This time might deviate from (a potentially also present) document/time
element since the latter represents the time when a certain evidence was checked whereas this element represents the time when the process was completed. Moreover, the overall verification process and evidence verification can be conducted by different parties (see document/verifier
). Presence of this element might be required for certain trust frameworks.¶
verification_process
: Optional. Unique reference to the identity verification process as performed by the claim provider. Used for identifying and retrieving details in case of disputes or audits. Presence of this element might be required for certain trust frameworks.¶
evidence
: Optional. JSON array containing information about the evidence the claim provider used to verify the end-user's identity as separate JSON objects. Every object contains the property type
which determines the type of the evidence. The claim recipient uses this information to process the evidence
property appropriately.¶
Important: Implementations shall ignore any sub-element not defined in this specification or extensions of this specification.¶
Based on the definition above and that there are a significant number of optional sub-elements it is informative to show a minimum conformant verified_claims
payload. There can be optionally much more detail included in an openid-ida-verified-claims conformant verified_claims
element when further detail needs to be transferred. The example is not normative.¶
{ "verified_claims": { "verification": { "trust_framework": "de_aml" }, "claims": {} } }¶
Members of the evidence
array are structured with the following elements:¶
type
: Required. The value defines the type of the evidence.¶
The following types of evidence are defined:¶
document
: Verification based on the content of a physical or electronic document provided by the end-user, e.g. a passport, ID card, PDF signed by a recognized authority, etc.¶
electronic_record
: Verification based on data or information obtained electronically from an approved, recognized, regulated or certified source, e.g. a government organization, bank, utility provider, credit reference agency, etc.¶
vouch
: Verification based on an attestation given by an approved or recognized natural person declaring they believe that the claim(s) presented by the end-user are, to the best of their knowledge, genuine and true.¶
electronic_signature
: Verification based on the use of an electronic signature that can be uniquely linked to the end-user and is capable of identifying the signatory, e.g. an eIDAS Advanced Electronic Signature (AES) or Qualified Electronic Signature (QES).¶
attachments
: Optional. Array of JSON objects representing attachments like photocopies of documents or certificates. Structure of members of the attachments
array is described in [Attachments].¶
Depending on the evidence type additional elements are defined, as described in the following.¶
document
The following elements are contained in an evidence sub-element where type is document
.¶
type
: Required with value set to document
.¶
check_details
: Optional. JSON array representing the checks done in relation to the evidence
. When present this array shall have at least one member.¶
check_method
: Required. String representing the check done, this includes processes such as checking the authenticity of the document, or verifying the user's biometric against an identity document. For information on predefined check_details
values see [predefined_values_page].¶
organization
: Optional. String denoting the legal entity that performed the check. This should be included if the claim provider did not perform the check itself.¶
check_id
: Optional. Identifier referring to the event where a check (either verification or validation) was performed. The claim provider shall ensure that this is present when evidence_ref
element is used. The claim provider shall ensure that the transaction identifier can be resolved into transaction details during an audit.¶
time
: Optional. Time stamp in ISO 8601 [ISO8601] YYYY-MM-DDThh:mm[:ss]TZD
format representing the date when the check was completed.¶
document_details
: Optional. JSON object representing the document used to perform the identity verification. It consists of the following properties:¶
type
: Required. String denoting the type of the document. For information on predefined document values see [predefined_values_page]. The claim provider may use other predefined values in which case the claim recipients will either be unable to process the assertion, just store this value for audit purposes, or apply bespoke business logic to it.¶
document_number
: Optional. String representing an identifier/number that uniquely identifies a document that was issued to the end-user. This is used on one document and will change if it is reissued, e.g., a passport number, certificate number, etc.¶
serial_number
: Optional. String representing an identifier/number that identifies the document irrespective of any personalization information (this usually only applies to physical artifacts and is present before personalization).¶
date_of_issuance
: Optional. The date the document was issued as ISO 8601 [ISO8601] YYYY-MM-DD
format.¶
date_of_expiry
: Optional. The date the document will expire as ISO 8601 [ISO8601] YYYY-MM-DD
format.¶
issuer
: Optional. JSON object containing information about the issuer of this document. This object consists of the following properties:¶
name
: Optional. Designation of the issuer of the document.¶
address
claim (see [OpenID])¶
country_code
: Optional. String denoting the country or supranational organization that issued the document as ISO 3166/ICAO 3-letter codes [ICAO-Doc9303], e.g., "USA" or "JPN". 2-letter ICAO codes may be used in some circumstances for compatibility reasons.¶
jurisdiction
: Optional. String containing the name of the region(s)/state(s)/province(s)/municipality(ies) that issuer has jurisdiction over (if this information is not common knowledge or derivable from the address).¶
derived_claims
: Optional. JSON object containing claims about the end-user which were derived from the document described in the evidence array member it is part of. When used the derived_claims
element has the following conditions:¶
derived_claims
element may contain any of the claims defined in section 5.1 of the OpenID Connect specification [OpenID] and the claims defined in [OpenID4IDAClaims].¶
derived_claims
element may also contain other end-user claims (not defined in the OpenID Connect specification [OpenID] nor in [OpenID4IDAClaims]) derived from the document described in the evidence array member it is part of.¶
derived_claims
element shall have corresponding claims in the claims
element of verified_claims
.¶
derived_claims
element is used it should be present in all members of the evidence
array and all claims under the claims
element of verified_claims
should have a corresponding claim in at least one derived_claims
element.¶
derived_claims
element shall not be empty.¶
electronic_record
The following elements are contained in an evidence sub-element where type is electronic_record
.¶
type
: Required with value set to electronic_record
.¶
check_details
: Optional. JSON array representing the checks done in relation to the evidence
.¶
check_method
: Required. String representing the check done. For information on predefined check_method
values see [predefined_values_page].¶
organization
: Optional. String denoting the legal entity that performed the check. This should be included if the claim provider did not perform the check itself.¶
check_id
: Optional. Identifier referring to the event where a check (either verification or validation) was performed. The claim provider shall ensure that this is present when evidence_ref
element is used. The claim provider shall ensure that the transaction identifier can be resolved into transaction details during an audit.¶
time
: Optional. Time stamp in ISO 8601 [ISO8601] YYYY-MM-DDThh:mm[:ss]TZD
format representing the date when the check was completed.¶
record
: Optional. JSON object representing the record used to perform the identity verification. It consists of the following properties:¶
type
: Required. String denoting the type of electronic record. For information on predefined identity evidence values see [predefined_values_page]. The claim provider may use other predefined values in which case the claim recipients will either be unable to process the assertion, just store this value for audit purposes, or apply bespoke business logic to it.¶
created_at
: Optional. The time the record was created as ISO 8601 [ISO8601] YYYY-MM-DDThh:mm[:ss]TZD
format.¶
date_of_expiry
: Optional. The date the evidence will expire as ISO 8601 [ISO8601] YYYY-MM-DD
format.¶
source
: Optional. JSON object containing information about the source of this record. This object consists of the following properties:¶
name
: Optional. Designation of the source of the electronic_record
.¶
address
claim (see [OpenID]): Optional.¶
country_code
: Optional. String denoting the country or supranational organization that issued the evidence as ISO 3166/ICAO 3-letter codes [ICAO-Doc9303], e.g., "USA" or "JPN". 2-letter ICAO codes may be used in some circumstances for compatibility reasons.¶
jurisdiction
: Optional. String containing the name of the region(s) / state(s) / province(s) / municipality(ies) that source has jurisdiction over (if it is not common knowledge or derivable from the address).¶
derived_claims
: Optional. JSON object containing claims about the end-user which were derived from the electronic record described in the evidence array member it is part of.¶
derived_claims
element may contain any of the claims defined in section 5.1 of the OpenID Connect specification [OpenID] and the claims defined in [OpenID4IDAClaims].¶
derived_claims
element may also contain other end-user claims (not defined in the OpenID Connect specification [OpenID] nor in [OpenID4IDAClaims]) derived from the electronic record described in the evidence array member it is part of.¶
derived_claims
element shall not be empty.¶
vouch
The following elements are contained in an evidence sub-element where type is vouch
.¶
type
: Required with value set to vouch
.¶
check_details
: Optional. JSON array representing the checks done in relation to the vouch
.¶
check_method
: Required. String representing the check done, this includes processes such as checking the authenticity of the vouch, or verifying the user as the person referenced in the vouch. For information on predefined check_method
values see [predefined_values_page].¶
organization
: Optional. String denoting the legal entity that performed the check. This should be included if the claim provider did not perform the check itself.¶
check_id
: Optional. Identifier referring to the event where a check (either verification or validation) was performed. The claim provider shall ensure that this is present when evidence_ref
element is used. The claim provider shall ensure that the transaction identifier can be resolved into transaction details during an audit.¶
time
: Optional. Time stamp in ISO 8601 [ISO8601] YYYY-MM-DDThh:mm[:ss]TZD
format representing the date when the check was completed.¶
attestation
: Optional. JSON object representing the attestation that is the basis of the vouch. It consists of the following properties:¶
type
: Required. String denoting the type of vouch. For information on predefined vouch values see [predefined_values_page]. The claim provider may use other than the predefined values in which case the claim recipients will either be unable to process the assertion, just store this value for audit purposes, or apply bespoke business logic to it.¶
reference_number
: Optional. String representing an identifier/number that uniquely identifies a vouch given about the end-user.¶
date_of_issuance
: Optional. The date the vouch was made as ISO 8601 [ISO8601] YYYY-MM-DD
format.¶
date_of_expiry
: Optional. The date the evidence will expire as ISO 8601 [ISO8601] YYYY-MM-DD
format.¶
voucher
: Optional. JSON object containing information about the entity giving the vouch. This object consists of the following properties:¶
name
: Optional. String containing the name of the person giving the vouch/reference in the same format as defined in section 5.1 (Standard Claims) of the OpenID Connect Core specification.¶
birthdate
: Optional. String containing the birthdate of the person giving the vouch/reference in the same format as defined in section 5.1 (Standard Claims) of the OpenID Connect Core specification.¶
address
claim (see [OpenID]): Optional.¶
country_code
: Optional. String denoting the country or supranational organization that issued the evidence as ISO 3166/ICAO 3-letter codes [ICAO-Doc9303], e.g., "USA" or "JPN". 2-letter ICAO codes may be used in some circumstances for compatibility reasons.¶
occupation
: Optional. String containing the occupation or other authority of the person giving the vouch/reference.¶
organization
: Optional. String containing the name of the organization the voucher is representing.¶
derived_claims
: Optional. JSON object containing claims about the end-user which were derived from the vouch described in the evidence array member it is part of (an example is presented later in this document)¶
derived_claims
element may contain any of the claims defined in section 5.1 of the OpenID Connect specification [OpenID] and the claims defined in [OpenID4IDAClaims].¶
derived_claims
element may also contain other end-user claims (not defined in the OpenID Connect specification [OpenID] nor in [OpenID4IDAClaims]) derived from the vouch described in the evidence array member it is part of.¶
derived_claims
element shall not be empty.¶
electronic_signature
The following elements are contained in an electronic_signature
evidence sub-element.¶
type
: Required with value set to electronic_signature
.¶
signature_type
: Required. String denoting the type of signature used as evidence. The value range might be restricted by the respective trust framework.¶
issuer
: Required. String denoting the certification authority that issued the signer's certificate.¶
serial_number
: Required. String containing the serial number of the certificate used to sign.¶
created_at
: Optional. The time the signature was created as ISO 8601 [ISO8601] YYYY-MM-DDThh:mm[:ss]TZD
format.¶
derived_claims
: Optional. JSON object containing claims about the end-user which were derived from the electronic signature described in the evidence array member it is part of.¶
derived_claims
element may contain any of the claims defined in section 5.1 of the OpenID Connect specification [OpenID] and the claims defined in [OpenID4IDAClaims].¶
derived_claims
element may also contain other end-user claims derived from the electronically signed object described in the evidence array member it is part of, such as elements of an advanced electronic signature described under eIDAS used to uniquely link the signed object to the signatory.¶
derived_claims
element shall not be empty.¶
During the identity verification process, specific document artifacts could be collected and depending on the trust framework, will be required to be stored for a specific duration. These artifacts can later be reviewed during audits or quality control for example. These artifacts include, but are not limited to:¶
When supported by the claim provider and requested by the claim recipient, these elements can be included in the verified claims response allowing the claims recipient to store these artifacts along with the verified claims information.¶
An attachment is represented by a JSON element. The definition of attachments and the schema representing them are described in [Attachments].¶
{ "verified_claims": { "verification": { "trust_framework": "eidas", "assurance_level": "substantial" }, "claims": { "given_name": "Max", "family_name": "Meier", "birthdate": "1956-01-28", "place_of_birth": { "country": "DE", "locality": "Musterstadt" }, "nationalities": [ "DE" ] } } }¶
{ "verified_claims": { "verification": { "trust_framework": "de_aml", "time": "2012-04-23T18:25Z", "verification_process": "513645-e44b-4951-942c-7091cf7d891d", "evidence": [ { "type": "document", "check_details": [ { "check_method": "pvp" }, { "check_method": "vpip" } ], "time": "2012-04-22T11:30Z", "document_details": { "type": "de_erp_replacement_idcard", "issuer": { "name": "Stadt Augsburg", "country": "DE" }, "document_number": "53554554", "date_of_issuance": "2010-04-23", "date_of_expiry": "2020-04-22" } }, { "type": "document", "check_details": [ { "check_method": "vpip" } ], "time": "2012-04-22T11:30Z", "document_details": { "type": "utility_statement", "issuer": { "name": "Stadtwerke Musterstadt", "country": "DE", "region": "Niedersachsen", "street_address": "Energiestrasse 33" }, "date_of_issuance": "2013-01-31" } } ] }, "claims": { "given_name": "Max", "family_name": "Meier", "birthdate": "1956-01-28", "place_of_birth": { "country": "DE", "locality": "Musterstadt" }, "nationalities": [ "DE" ], "address": { "locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "An der Weide 22" } } } }¶
{ "verified_claims": [ { "verification": { "trust_framework": "eidas", "assurance_level": "substantial" }, "claims": { "given_name": "Max", "family_name": "Meier", "birthdate": "1956-01-28", "place_of_birth": { "country": "DE", "locality": "Musterstadt" }, "nationalities": [ "DE" ] } }, { "verification": { "trust_framework": "de_aml", "time": "2012-04-23T18:25Z", "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7", "evidence": [ { "type": "document", "method": "pipp", "time": "2012-04-22T11:30Z", "document": { "type": "idcard" } } ] }, "claims": { "address": { "locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "An der Weide 22" } } } ] }¶
{ "verified_claims": { "verification": { "trust_framework": "de_aml", "time": "2012-04-23T18:25Z", "verification_process": "513645-e44b-4951-942c-7091cf7d891d", "evidence": [ { "type": "document", "time": "2012-04-22T11:30Z", "document_details": { "type": "de_erp_replacement_idcard", "document_number": "53554554", "date_of_expiry": "2020-04-22" }, "derived_claims": { "given_name": "Max", "family_name": "Meier", "birthdate": "1956-01-28", "nationalities": [ "DE" ] } }, { "type": "document", "time": "2012-04-22T11:30Z", "document_details": { "type": "utility_statement", "date_of_issuance": "2013-01-31" }, "derived_claims": { "given_name": "Maximillion", "family_name": "Meier", "address": { "locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "An der Weide 22" } } } ] }, "claims": { "given_name": "Max", "family_name": "Meier", "birthdate": "1956-01-28", "nationalities": [ "DE" ], "address": { "locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "An der Weide 22" } } } }¶
The working group has identified no security considerations that pertain directly to this specification.¶
The data structures described in this specification will contain personal information. Standards referencing this specification and implementers using this specification should consider the secure transport of these structures and security and privacy implications that may arise from their use.¶
This specification requests registration of the following value in the IANA "JSON Web Token Claims Registry" established by [RFC7519].¶
verified_claims
verified_claims
¶
The following people at yes.com and partner companies contributed to the concept described in the initial contribution to this specification: Karsten Buch, Lukas Stiebig, Sven Manz, Waldemar Zimpfer, Willi Wiedergold, Fabian Hoffmann, Daniel Keijsers, Ralf Wagner, Sebastian Ebling, Peter Eisenhofer.¶
We would like to thank Julian White, Bjorn Hjelm, Stephane Mouy, Joseph Heenan, Vladimir Dzhuvinov, Azusa Kikuchi, Naohiro Fujie, Takahiko Kawasaki, Sebastian Ebling, Marcos Sanz, Tom Jones, Mike Pegman, Michael B. Jones, Jeff Lombardo, Taylor Ongaro, Peter Bainbridge-Clayton, Adrian Field, George Fletcher, Tim Cappalli, Michael Palage, Sascha Preibisch, Giuseppe De Marco, Nick Mothershaw, Hodari McClain, Dima Postnikov and Nat Sakimura for their valuable feedback and contributions that helped to evolve this specification.¶
Copyright (c) 2024 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.¶