TOC |
|
OpenID Providers within OpenID Connect assume many roles, one of these is providing End-User claims to relying parties at the consent of the End-User such as their name or date of birth. OpenID Connect defines multiple models under which claims are provided and relied upon by a relying parties, including simple, aggregated and distributed claims. This document focuses on elaborating upon the aggregated model outlined in section 5.6.2 of OpenID Connect core by defining the full life-cycle of aggregated claims and the new roles of the entities involved in an aggregated claims model.
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 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.
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 participants). 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 has 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.
OpenID Connect is a selective claims disclosure mechanism. When a set of claims included in its response is about an entity authentication event, it works as an entity authentication federation mechanism, but it can deliver other claims selected by the subject as well.
In the OpenID Connect specification, it is assumed that there are many sources of claims. Each claim is associated with its authoritative source so there naturally will be many authoritative sources. Claim sources can be corroborative, i.e., not authoritative, as well. In total, there will be many Claim Set sources in OpenID Connect Framework. These Claim sources are called Issuing Authorities in OpenID Connect. Issuing-Authority (IA) is just an Identity-Agent (IdA), but it does not provide the claims about the current authentication event and its associated subject identifier authoritatively. Note that Issuing-Authority can act as an Identity-Agent in other transactions. Whether it is called IdA or IA is depending on their role in a particular transaction.
There are four main actors in the OpenID Connect aggregated claims model.
An IdA can provide an CC the claims by value or by reference.
By value is the case where an IdA collects claims and their values from IAs and aggregate them in one package to provide to the CC. This model is called Aggregated Claims Model.
By value is the case where the IdA does not collect and provide the value but just provide the reference and its access information to the CC. This model is called Distributed Claims Model.
In either case, there has to be strong binding between the subject in the claim sets provided by IAs and the subject in the ID Token provided by the IdA. Conceptually, it can be done through Subject value correlation or through the correlation of signing key materials. Regardless of the methods, there has to be this binding. Otherwise, the provided claims cannot be trusted to be linked to the authenticated subject.
This document defines how to do this binding even in the case of ephemeral subject identifier in which case the sub value of the ID Token will change every time the subject visits the CC. This allows anonymous attribute based authentication where an CC cannot link two visits by the subject without using other facilities.
By supporting the case of ephemeral subject identifier, pairwise pseudonymous identifier and omni-directional identifier cases are also covered.
Another feature that this document provides is the way to avoid multiple consent screen per CC authorization request. If OpenID Connect Core spec is used to build Aggregated Claims Model naively, it may result in many consent screens per CC request. For example, if four IAs and one IdA is involved in the request, then, there may be five consent screens. This is too onerous. This document defines a mechanism to consolidate it into one consent screen. This is done through one "IdA User Setup Phase" per IA that the IdA obtains the consent from the subject to obtain claims from the IA for the purpose of creating aggregated and distributed claims response for future CC requests in which IdA will collect a new consent from the subject.
The mechanism used for this is to obtain an access token and a refresh token that corresponds to a suitably wide scope for the purpose. While the claims at the time of an CC request can be obtained from the UserInfo endpoint, this document defines a new endpoint called claims endpoint. It is almost the same as the UserInfo endpoint, but there are a few important differences:
Note that while Userinfo Endpoint was conceived to support multiple response types, e.g., support for SCIM schema, the exact method was not specified at the time of the publication.
This new Claims Endpoint allows the specification of the response schema and media type, e.g., OIDC JWT, OIDC4IDA JWT, W3C Verifiable Claims in JWT and JSON-LD, SCIM 2.0 in JWT, etc. It is done so in an extensible manner (using registry tbd).
This implies that there will be an impact to the authentication and claims request that an CC makes. It may optionally want to specify its preferred format for the Claim Sets to be received. Therefore, this document also defines a new parameter to express its preference.
There are four phases defined in this document.
Note that distributed claims model is out of scope of this document.
Intended reader of this document is the developer and systems architect who builds attributes and claims base systems.
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
In the .txt version of this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. In the HTML version of this document, values to be taken literally are indicated by the use of this fixed-width font.
All uses of JSON Web Signature (JWS) JWS and JSON Web Encryption (JWE) JWE data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used.
1.
Scope
2.
Normative references
3.
Terms and definitions
4.
Symbols and abbreviated terms
5.
Actors
5.1.
Subject (User)
5.2.
Claims-Consumer (CC)
5.3.
Issuing-Authority (IA)
5.3.1.
Claims Endpoint
5.4.
Identity-Agent (IdA)
5.4.1.
c_token
6.
Discovery Phase
7.
Registration Phase
8.
Setup Phase
8.1.
Overview
8.2.
Authorization request
8.3.
Token Endpoint Response
9.
Delivery Phase (CC Phase)
9.1.
Overview
9.2.
Claims Request by CC to IdA
9.3.
CC authentication and the request verification
9.4.
Subject Granting
9.5.
Claims Collection
9.5.1.
Claims Endpoint Request
9.5.2.
Signed Claimset Request using a Decentralized Identifier
9.5.3.
Claims Endpoint Response
9.5.3.1.
Claimset in OIDC JWS format
9.5.3.2.
Claimset in W3C VC format
9.5.4.
Claims Endpoint Error Response
9.5.5.
Claims Endpoint Verification
9.6.
Claims Delivery
9.7.
Claims Verification
10.
Security Considerations
11.
Privacy Considerations
12.
References
12.1.
Normative references
§
Authors' Addresses
TOC |
This document specifies the methods for
TOC |
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.
TOC |
For the purpose of this document, the terms defined in RFC6749, RFC6750, RFC7636, OpenID Connect Core apply. In addition, following terms are defined as a shorthand for the definition text that follows.
3.1
Issuing-Authority
party that issues attested claims
3.2
Claims-Consumer
party that verifies and consumes the provided claim sets
3.3
Identity-Agent
party that acts as an RP to Issuing-Authorities and OP to Claims-Consumers
Note to entry: A Digital Identity Wallet is a type of IdA.
TOC |
IA – Issuing-Authority
IdA – Identity-Agent
CC – Claims-Consumer
DID - Decentralized Identifier
HTTP - Hyper Text Transfer Protocol
TLS - Transport Layer Security
VC - W3C Verifiable Credential
VP - W3C Verifiable Presentation
W3C - World Wide Web Consortium
TOC |
In this document, there are four main actors.
They are topologically connected as in the following diagram.
+---------+ +-----------| Subject |--------+ | grants +---------+ | v | | +------+ | instructs | allows | IA |----+ | | +------+ | v v . | +-------+ +------+ . |----| IdA |-----| CC | . | +-------+ +------+ +------+ | | IA |----+ +------+
Relationships among actors
|
TOC |
Subject is the entity that grants access to the claims at IAs and the IdA. In this system, the Subject grants IA to provide IdA the Claims for the purpose of providing those claims with other claims to potentially unspecified CCs under the Subject's direction.
This request from the IdA to the IA is sent by the Subject's instruction. The Subject also allows IdA to potentially store the obtained claims.
The Subject also allows CC to make a claims request to the IdA, typically for the Subject to receive some services from the CC.
TOC |
CC is an actor that typically provides some service to the Subject. To perform the service, the CC obtains some claims about the Subject from IdA. The basis for the processing of the Subject's claims by the CC can be performance of contract, consent, and other lawful basis.
TOC |
IA, Issuing-Authority, is a role assumed by an Identity-Agent
that supports signed claims according to this document.
Specifically, it supports an extension to bind the
authentication response that CCs received from the IdA
to the claim sets that it provides.
The provision for the Issuing-Authority are as follows:
TOC |
The Claims Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated Subject. To obtain the requested Claims about the Subject, the IdA acting as a Client makes a request to the Claims Endpoint of the IA using an Access Token obtained through OpenID Connect Authentication. These Claims can be represented in variety of format as requested.
This document defines the following request parameters for the Claims Endpoint request:
** Editor's NOTE ** Is there a way to specify the CCs that are registered to the IdA?
The provision for the Claims Endpoint are as follows:
** EDITOR'S NOTE ** I guess there are other provisions. The above probably needs to be tweaked as well.
TOC |
IdA is an entity that acts as an Identity-Agent to the CC. Also, IdA acts as a Claims-Consumer to IAs.
The provision for the IdA is as follows:
** EDITOR'S NOTE ** I guess there are other provisions.
TOC |
c_token Authorization Request parameter lists individual Claims that the IdA asks the IA to be returned from the Claims Endpoint. This top-level member is a JSON object with the names of the individual Claims being requested as the member names, and the values are defined as in 5.5.1 of OpenID Connect 1.0 OIDC.
TOC |
Before registering itself as an OAuth Client to an IA, the IdA needs to obtain configuration information from the IA, including its Authorization Endpoint and Token Endpoint locations.
This information is obtained via Discovery, as described in OpenID Connect Discovery 1.0 OpenID.Discovery, or may be obtained via other mechanisms.
This document adds the following Identity-Agent Metadata to the OpenID Connect Discovery 1.0 OpenID.Discovery response:
Additionally, the following optional OpenID Connect Discovery 1.0 OpenID.Discovery parameters are now required in the Issuing-Authority Metadata:
- claim_types_supported
- The JSON array MUST contain the values normal, distributed, ... .
- claims_supported
- A JSON array containing a list of the Claim Names of the Claims that the Identity-Agent MAY be able to supply values for.
- claims_parameter_supported
- The value MUST be true to support the claims request parameter.
- request_parameter_supported
- The value MUST be true to support the request request parameter.
- request_uri_parameter_supported
- The value MUST be true to support the request_uri request parameter.
- claimset_supported
- Boolean value indicating that the Issuing-Authority supports the claimset flows.
- claimset_formats_supported
- A JSON array of strings identifying the resulting format of the claimset issued at the end of the flow.
- claimset_claims_supported
- A JSON array of strings identifying the claim names supported within an issued claimset.
- claimset_name
- A human-readable string to identify the name of the claimset offered by the provider.
- dids_supported
- Boolean value indicating that the OpenID provider supports the resolution of decentralized identifiers.
- did_methods_supported
- A JSON array of strings representing Decentralized Identifier Methods that the OpenID provider supports resolution of.
If the IA supports OpenID Connect for Identity Assurance 1.0 OpenID.IDA, the supported OpenID Connect for Identity Assurance 1.0 OpenID.IDA features MUST be published as specified in section 7 of OpenID Connect for Identity Assurance 1.0 OpenID.IDA.
If the IA supports W3C Verifiable Credentials, the IA MUST advertise it with the following metadata:
** Editors Note: Tobias, could you fill in here? **
The following is a non-normative example of the relevant entries in the openid-configuration metadata for an OpenID Provider supporting the claimset issuance flow
{ "dids_supported": true, "did_methods_supported": [ "did:ion:", "did:elem:", "did:sov:" ], "claimset_supported": true, "claimset_endpoint": "https://server.example.com/credential", "claimset_formats_supported": [ "w3cvc-jsonld", "jwt" ], "claimset_claims_supported": [ "given_name", "last_name", "https://www.w3.org/2018/credentials/examples/v1/degree" ], "claimset_name": "University Credential" }
If the IA supports mDL format, the IA MUST advertise it with the following metadata:
** Editors Note: Tony or Kristina, could you fill in here? **
If the IA supports SCIM format, the IA MUST advertise it with the following metadata:
** Editors Note: SCIM experts, could you fill in here? **
TOC |
Before starting to make requests to an IA, the IdA MUST register itself to the IA. The registration SHOULD be performed via Dynamic Registration, as described in OpenID Connect Dynamic Client Registration 1.0.
This document adds the following Client Metadata to the OpenID Connect Dynamic Client Registration :
claims_signed_response_alg Required. JWS alg algorithm JWA JWA REQUIRED for signing Claims Responses. The value none MUST NOT be used. If this is specified, the response will be JWT JWT serialized, and signed using JWS. The default, if omitted, is RS256.
claims_encrypted_response_alg Optional. JWE alg algorithm JWA JWA REQUIRED for encrypting Claims responses to the client. If both signing and encryption are requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in JWT JWT. The default, if omitted, is that no encryption is performed.
claims_encrypted_response_enc Optional. JWE enc algorithm JWA JWA REQUIRED for encrypting Claims responses. If claims_encrypted_response_enc is specified, the default for this value is A128CBC-HS256. When claims_encrypted_response_enc is included, claims_encrypted_response_alg MUST also be provided.
Authentication requests to the Issuing-Authority's Authorization Endpoint should be signed or signed and encrypted. In order to support a more diverse set of claims, requests for claims should be made using Request Objects which are signed or signed and encrypted by registering the appropriate values for the following Client Metadata registration parameters:
TOC |
TOC |
In this phase, the IdA obtains an access token (and optionally refresh token) that is bound to the current user so that the IdA can obtain the claims about the current user from the IA subsequently without taking the user to the IA and show them the consent dialogue for every CC requests.
** Editor's NOTE:** Originally, it had: The Claims to be granted MUST be specified with c_token parameter.
TOC |
A Signed Claim Set Request uses the OpenID and OAuth2.0 request parameters as outlined in section 3.1.2.1 of OpenID Connect core, except for the following additional constraints.
- claimset_format
- REQUIRED. Determines the format of the signed claim set returned at the end of the flow, values supported by the IA are advertised in their openid-configuration metadata, under the claimset_formats_supported attribute.
- sub_jwk
- OPTIONAL. Used when making a Signed Claimset Request, defines the key material the IdA is requesting the claim set to be bound to the key responsible for signing the request object. The value is a JSON Object that is a valid JWK.
** Editors Note: ** DISCUSS the following paragraph. the parameter did should be sent in the claims collection phase rather than here?
- did
- OPTIONAL. Defines the relationship between the key material the IdA is requesting the claimset to be bound to and a decentralized identifier. Processing of this value requires the IA to support the resolution of decentralized identifiers which is advertised in their openid-configuration metadata, under the dids_supported attribute. The value of this field MUST be a valid decentralized identifier.
** Editors Note: ** DISCUSS the following paragraph. Normal client authentication should be a primary choice instead?
Public private key pairs are used by a requesting IdA to establish a means of binding to the resulting signed claim set. An IdA making a Claims Request to an IA MUST prove control over this binding mechanism during the request, this is accomplished through the extended usage of a signed request defined in OpenID Connect Core.
The IA MUST show a dialogue to the Subject explaining that the IdA will be getting signed claims set from this IA as appropriate to provide claims to CCs as directed by the Subject.
The dialogue MUST provide the link to the policy_url provided by the IdA during its registration.
The actual act of granting MUST involve active user interaction.
The grant that is to be obtained in this phase SHOULD be sufficiently large so that it will reduce the number of times that IdA needs to take the Subject to the IA to obtain additional grants.
TOC |
Successful and Error Authentication Response are in the same manner as OpenID Connect Core 1.0 with the code parameter always being returned with the Authorization Code Flow. ** DISCUSS **
On Request to the Token Endpoint the grant_type value MUST be authorization_code inline with the Authorization Code Flow and the code value included as a parameter.
The following is a non-normative example of a response from the token endpoint, whereby the access_token authorizes the Claimset Holder to request a credential from the claimset endpoint.
{ "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ", "token_type": "bearer", "expires_in": 86400, "id_token": "eyJodHRwOi8vbWF0dHIvdGVuYW50L..3Mz" }
TOC |
TOC |
In Delivery Phase, the claims are delivered to CC. To do so, it typically goes through the following steps:
Claims Collection MAY be done out of sync. That is, the signed claim sets can be obtained before the CC requests. This is typically the case when claims are provided through the W3C Verifiable Credentials container.
TOC |
For an CC to request claims according to this document, the CC
TOC |
Upon receipt of the request, the IdA
NOTE: CC MUST be authenticated at one point or another before completion of the transaction.
TOC |
After verifying the request, the IdA
TOC |
The IdA collects the required claims from relevant Claims Endpoints. This process can be performed before the CC's request, in which case IdA stores the obtained signed claim set for a later day use.
The Claims Endpoint is an OAuth 2.0 Protected Resource that when called, returns Claims about the authenticated Subject in the form of a signed claim set. To obtain a claim set on behalf of the Subject, the IdA makes a request to the Claims Endpoint using an Access Token obtained through OpenID Connect Authentication stated above.
Communication with the Credential Endpoint MUST utilize TLS. See Section TBD for more information on using TLS.
The Claims Endpoint MUST support the use of HTTP POST methods defined in RFC 2616 [RFC2616].
The Claims Endpoint SHOULD support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable JavaScript Clients to access the endpoint.
The Claims Endpoint MUST support either MTLS or DPOP.
TOC |
For claims collection, the IdA
Additionally,
The following is a non-normative example of a Claims Endpoint Request:
POST /claims HTTP/1.1 HTTP/1.1 Host: server.example.com Authorization: Bearer SlAV32hkKG claims={"uid":"id8837395937","email":{"essential":true},"email_verified":{"essential":true}}&aud={["client1234"]}
** Editor's Note ** An alternative way.
A non-normative example of a Signed Credential request.
POST /claims HTTP/1.1 Host: https://issuer.example.com Authorization: Bearer <access-token> Content-Type: application/json { "request": <signed-jwt-request-obj> }
where the decoded payload of the request parameter is as follows:
{ "aud": "https://issuer.example.com", "iss": "https://wallet.example.com", "sub": "urn:uuid:dc000c79-6aa3-45f2-9527-43747d5962a5", "sub_jwk" : { "crv":"secp256k1", "kid":"YkDpvGNsch2lFBf6p8u3", "kty":"EC", "x":"7KEKZa5xJPh7WVqHJyUpb2MgEe3nA8Rk7eUlXsmBl-M", "y":"3zIgl_ml4RhapyEm5J7lvU-4f5jiBvZr4KgxUjEhl9o" }, "claimset_format": "w3cvc-jwt", "nonce": "43747d5962a5", "iat": 1591069056, "exp": 1591069556 }
The process will be repeated to as many Claims Endpoints as necessary.
TOC |
Usage of Decentralized Identifiers
TODO improve this section
Decentralized identifiers are a resolvable identifier to a set of statements about the did subject including a set of cryptographic material (e.g. public keys). Using this cryptographic material, a decentralized identifier can be used as an authenticatable identifier in a claimset, rather than using a public key directly.
An IdA submitting a signed Claim Set Request can request, that the resulting claim set be bound to the IdA through the usage of decentralized identifiers by using the did field.
An IdA prior to submitting a claim set request SHOULD validate that the IA supports the resolution of decentralized identifiers by retrieving their openid-configuration metadata to check if an attribute of dids_supported has a value of true.
The IdA SHOULD also validate that the IA supports the did method to be used in the request by retrieving their openid-configuration metadata to check if an attribute of did_methods_supported contains the required did method.
An IA processing a claim set request featuring a decentralized identifier MUST follow the following additional steps to validate the request.
If any of the steps fail then the IA MUST respond to the request with the Error Response parameter, section 3.1.2.6. with Error code: invalid_did.
The following is a non-normative example of requesting the issuance of a claimset that uses a decentralized identifier.
{ "response_type": "code", "client_id": "IAicV0pt9co5nn9D1tUKDCoPQq8BFlGH", "sub_jwk" : { "crv":"secp256k1", "kid":"YkDpvGNsch2lFBf6p8u3", "kty":"EC", "x":"7KEKZa5xJPh7WVqHJyUpb2MgEe3nA8Rk7eUlXsmBl-M", "y":"3zIgl_ml4RhapyEm5J7lvU-4f5jiBvZr4KgxUjEhl9o" }, "did": "did:example:1234", "redirect_uri": "https://Client.example.com/callback", "claimset_format": "w3cvc-jsonld" }
TOC |
Upon receipt of the request, the Claims Endpoint Response is returned in the top level member of the JSON payload named claimset, of which the format is indicated by another top level memberformat.
format : REQUIRED. The proof format the claimset was returned in. For example oidc-jws or w3cvc-jsonld or w3cvc-jwt. claimset : REQUIRED. A cryptographically verifiable proof in the defined proof format. Most commonly a Linked Data Proof or a JWS.
The following is a non-normative example:
{ "format": "w3cvc-jsonld", "claimset": <claimset> }
TOC |
If the claimset is provided as oidc-jws, the claimset
NOTE: the combination of op_iss and sub is used to correlated to the IdA response to the CC later.
The following is a non-normative example of such:
To be provided.
TOC |
Formats of the claimset can vary, examples include JSON-LD or JWT based Credentials, the IA SHOULD make their supported claimset formats available at their openid-configuration metadata endpoint.
The following is a non-normative example of a claim set issued as a W3C Verifiable Credential 1.0 compliant format in JSON-LD.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.gov/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "did:key:z6MkjRagNiMu91DduvCvgEsqLZDVzrJzFrwahc4tXLt9DoHd", "issuanceDate": "2020-03-10T04:24:12.164Z", "credentialSubject": { "id": "urn:uuid:dc000c79-6aa3-45f2-9527-43747d5962a5", "jwk": { "crv":"secp256k1", "kid":"YkDpvGNsch2lFBf6p8u3", "kty":"EC", "x":"7KEKZa5xJPh7WVqHJyUpb2MgEe3nA8Rk7eUlXsmBl-M", "y":"3zIgl_ml4RhapyEm5J7lvU-4f5jiBvZr4KgxUjEhl9o" }, "givenName": "John", "familyName": "Doe", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "Ed25519Signature2018", "created": "2020-04-10T21:35:35Z", "verificationMethod": "did:key:z6MkjRagNiMu91DduvCvgEsqLZDVzrJzFrwahc4tXLt9DoHd#z6MkjRagNiMu91DduvCvgEsqLZDVzrJzFrwahc4tXLt9DoHd", "proofPurpose": "assertionMethod", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..l9d0YHjcFAH2H4dB9xlWFZQLUpixVCWJk0eOt4CXQe1NXKWZwmhmn9OQp6YxX0a2LffegtYESTCJEoGVXLqWAA" } }
The following is a non-normative example of a claims endpoint response for the request shown above.
{ "format": "w3cvc-jsonld", "credential": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.gov/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://issuer.edu", "issuanceDate": "2020-03-10T04:24:12.164Z", "credentialSubject": { "id": "did:example:1234", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "Ed25519Signature2018", "created": "2020-04-10T21:35:35Z", "verificationMethod": "https://issuer.edu/keys/1", "proofPurpose": "assertionMethod", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..l9d0YHjcFAH2H4dB9xlWFZQLUpixVCWJk0eOt4CXQe1NXKWZwmhmn9OQp6YxX0a2LffegtYESTCJEoGVXLqWAA" } } }
The following is a non-normative example of a Claim Set issued as a JWT
ewogICJhbGciOiAiRVMyNTYiLAogICJ0eXAiOiAiSldUIgp9.ewogICJpc3MiOiAiaXNzdWVyIjogImh0dHBzOi8vaXNzdWVyLmVkdSIsCiAgInN1YiI6ICJkaWQ6ZXhhbXBsZToxMjM0NTYiLAogICJpYXQiOiAxNTkxMDY5MDU2LAogICJleHAiOiAxNTkxMDY5NTU2LAogICJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy9leGFtcGxlcy92MS9kZWdyZWUiOiB7CiAgICAgImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxL3R5cGUiOiAiQmFjaGVsb3JEZWdyZWUiLAogICAgICJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy9leGFtcGxlcy92MS9uYW1lIjogIkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiCiAgfQp9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
And the decoded Claim Set of the JWT
{ "iss": "https://issuer.example.com", "sub": "urn:uuid:dc000c79-6aa3-45f2-9527-43747d5962a5", "sub_jwk" : { "crv":"secp256k1", "kid":"YkDpvGNsch2lFBf6p8u3", "kty":"EC", "x":"7KEKZa5xJPh7WVqHJyUpb2MgEe3nA8Rk7eUlXsmBl-M", "y":"3zIgl_ml4RhapyEm5J7lvU-4f5jiBvZr4KgxUjEhl9o" }, "iat": 1591069056, "exp": 1591069556, "https://www.w3.org/2018/credentials/examples/v1/degree": { "https://www.w3.org/2018/credentials/examples/v1/type": "BachelorDegree", "https://www.w3.org/2018/credentials/examples/v1/name": "Bachelor of Science and Arts" } }
TOC |
When an error condition occurs, the Claims Endpoint returns an Error Response as defined in Section 3 of OAuth 2.0 Bearer Token Usage RFC6750. (HTTP errors unrelated to RFC 6750 are returned to the User Agent using the appropriate HTTP status code.)
The following is a non-normative example of a Claims Endpoint Error Response:
HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
TOC |
Upon receipt of the response, the IdA
TOC |
Once the necessary claim sets were collected, the IdA creates the Aggregated Claims response to be returned.
The response can be returned as ID Token or Userinfo Response ( or Claims Endpoint Response).
The aggregated claims response is constructed as follows:
TOC |
For Claims Verification,
TOC |
TBD
TOC |
TBD
TOC |
TOC |
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.
BCP14 - Key words for use in RFCs to Indicate Requirement Levels
RFC6749 - The OAuth 2.0 Authorization Framework
RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
RFC7636 - # Proof Key for Code Exchange by OAuth Public Clients
BCP212 - OAuth 2.0 for Native Apps
RFC6819 - OAuth 2.0 Threat Model and Security Considerations
BCP195 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
OIDC - OpenID Connect Core 1.0 incorporating errata set 1
OpenID.Discovery - OpenID Connect Discovery 1.0
OpenID.Registration - OpenID Connect Registration 1.0
OpenID.IDA - OpenID Connect for Identity Assurance 1.0
MTLS - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
JWT - JSON Web Token
JWS - JSON Web Signature
JWE - JSON Web Encryption
JWA - JSON Web Algorithms
TOC |
Nat Sakimura | |
NAT.Consulting | |
Email: | nat@nat.consulting |
Edmund Jay | |
Illumila | |
Email: | ejay@illumi.la |
Tobias Looker | |
MATTR Ltd | |
Email: | tobias.looker@mattr.global |