siop-v2 September 2021
Yasuda, et al. Standards Track [Page]
Workgroup:
connect
Internet-Draft:
openid-connect-self-issued-v2-1_0-04
Published:
Intended Status:
Standards Track
Authors:
K. Yasuda
Microsoft
M. Jones
Microsoft
T. Looker
Mattr

Self-Issued OpenID Provider v2

Abstract

OpenID Connect defines mechanism by which an End-user can leverage an OpenID Provider (OP) to release identity information (such as authentication and attributes) to a Relying Party (RP) which can act on that information.

This specification extends OpenID Connect with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP which is within the End-User's local control. End-users can leverage Self-Issued OPs to authenticate themselves and present claims directly to the Relying Parties. This allows users to interact with RPs directly, without relying on a third-party provider or requiring the End-User to operate their own hosted infrastructure.

Table of Contents

1. Introduction

This specification extends OpenID Connect with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP which is within the End-User's local control. End-users can leverage Self-Issued OPs to authenticate themselves and present claims directly to Relying Parties. This allows users to interact with RPs directly, without relying on a third-party provider or requiring the End-User to operate their own hosted infrastructure.

An OP releases identity information such as End-user authentication in the form of an ID Token. An RP will typically trust an ID token based the relationship between the RP and OP. The OP has a reputation-based stake with both RPs and End-Users to provide correct information.

A Self-Issued ID Token is an ID Token issued by a Self-Issued OP. A Self-Issued ID Token differs in that the trust relationship is directly with the End-user.

Because a Self-Issued ID Token does not have the broad reputational trust of a traditional hosted OP, claims by about the End-user (e.g. birthdate) are by default self-asserted and non-verifiable. Separate specifications such as [OIDC4VP] describe how to present claims from third-party sources which are cryptographically verifiable.

The extensions defined in this specification provide the protocol and policy-level changes needed to support this model of Self-Issued Identity Providers. Aspects not defined in this specification are expected to continue to follow OpenID Connect Core 1.0.

Note: This specification replaces Self-Issued OpenID Connect Provider DID Profile v0.1 and was written as a working item of a liaison between Decentralized Identity Foundation and OpenID Foundation.

2. Use-cases

2.1. Resilience against Sudden or Planned OP Unavailability

An OpenID Provider's infrastructure may become unavailable or even destroyed due to natural disasters such as hurricanes, tsunamis and fires, or may be removed from service as a planned business decision. As Self-Issued OPs are local to the End-user environment, there is resilience against such events simultaneously affecting a significant portion of otherwise unimpacted End-Users.

2.2. Authentication at the edge

As internet-connected smartphones have risen in availability, traditionally in-person interactions and services have begun to be optimized with digital alternatives. These services often have requirements for digital authentication and for other identity credentials. Self-Issued OPs can provide this authentication directly, without needing to delegate to remote, hosted OPs. This potentially allows for increased efficiency as well as allowing for authentication in environments which may have reduced connectivity.

2.3. Sharing credentials from several issuers in one transaction

When End-users apply to open a banking account online, in most countries they are required to submit scanned versions of the required documents. These documents are usualy issued by different authorities, and hard to be verified in a digital form. A Self-issued OP directly representing the user may have access to a greater set of such information as credentials, while a traditional OP may not have a business relationship which enables access to such a breadth of information. Self-Issued OPs could aggregate credentials from multiple sources, then release them within a single transaction to a relying party. The relying party can then verify the authenticity of the information to make the necessary business decisions.

2.4. Aggregation of multiple personas under one Self-Issued OP

End-users often use several hosted OpenID Providers for different Relying Parties. While there are many reasons to do this, often this is done to have separately maintained identities, such as keeping a work-related persona separate from a personal persona. An End-user may do this to specifically represent different sets of claims, or because they what to prevent relying parties from correlating their activities by using the same OP. The usage of multiple OPs can create friction later, as the end-user may return later having forgot which OP they used for the relying party.

A single Self-Issued OP can be chosen by the End-user based on its capability to meet specific needs and privacy concerns. The separately-defined ability to present third-party credentials allows the RP to accept Self-Issued ID Tokens while still evaluating attributes using reputational trust of the credential issuers.

3. Scope

As a Self-Issued OP may be running locally as a native application or progressive web application, the RP may not have a network-addressable endpoint to communicate directly with the OP. This specification leverages the implicit flow of OpenID Connect to communicate with such locally-running OP, and extends OpenID Connect Discovery to represent the differences from traditional OPs.

This document is scoped for a deployment model where Self-Issued OP is deployed on an End-user's device.

This specification defines:

This specification defines extensions to the OpenID Connect implicit flow to invoke a Self-Issued OP from a Relying Party. It also proposes user experience behavior when no appropriate Self-Issued Op is available locally.

OpenID Connect typically leverages a registration between a Client (acting as a RP) and the OP, which pre-establishes supported functionality before a request has been made. This may be done statically, or may leverage a combination of OpenID Connect Discovery and OpenID Connect Dynamic Client Registration.

Relying Parties typically cannot pre-establish registration with a Self-Issued OP, as each End-user might be represented by a different, locally-controlled Self-Issued OP instance. This specification extends the authentication request with a mechanism with additional dynamic registration techniques for feature negotiation.

A cryptographically-verifiable identifier is an identifier which is either based upon or can be resolved to cryptographic key material. Self-Issued OPs can prove possession of the underlying key during the OpenID message exchange with the RP. Future exchanges based on the same identifier serve to strongly re-authenticate the End-user.

This specification defines a subject identifier which is a thumbprint of the public key material. The public key itself is shared within the id_token as a JSON Web Key (JWK). The cryptographic algorithm needs to be supported by both the Self-Issued OP and RP.

This specification also allows for resolvable identifiers, which are URI which can resolve various types of authoritative data underneath an appropriate resolution method. Resolvable identifiers may be used as the subject identifier when they can be resolved to a set one or more of cryptographic keys that identify the subject. In addition to cryptographic algorithms, both the Self-Issued OP and RP need to support the resolution method. The resolution method is based on a the URI itself, such as a "https" resolution method. One example of such a resolvable identifier would be a Decentralized Identifier (DID), where resolution methods would typically also include the DID Method, e.g. "did:web".

For compatibility with the existing JWS/JWE-based cryptography of OpenID Connect, it is assumed such resolved cryptographic identities are representable as a JSON Web Key Set (JWKS). Each key in the set would have a cryptographic algorithm, key identifier, and associated key material.

The following are considered out of scope of this document:

A traditional OP could release additional claims about the user within an ID Token such as a verified email address. The trust in the validity of the claim is based on the trust between the RP and OP.

A Self-Issued OP can present two types of claims - self-attested claims and claims from a third-party issuer which are cryptographically verifiable.

This specification relies on other specifications to define the method to present credentials from third-party issuers. One such example is [OIDC4VP], which describes the usage of Verifiable Credentials and Verifiable Presentations with OpenID Connect.

The user might want to use her SIOP, run on her smartphone, to login to or share claims with an RP she is using on a dfferent device, e.g. a tablet or workstation.

Out of Scope: * Provisioning of aggregated credentials

The mechanism for a Self-Issued OP to acquire credentials which can be presented is out of scope of this document. Similar to presentation, a traditional OP may also wish to acquire third-party credentials to present to Relying Parties. One mechanism to provision credentials is being defined within the Claims Aggregation specification.

4. Terms and definitions

Common terms in this document come from four primary sources: DID-CORE, VC-DATA, RFC6749 and OpenID-Core. In the case where a term has a definition that differs, the definition below is authoritative.

4.1. Abbreviations

  • Self-Issued OP: Self-Issued OpenID Provider

  • RP: Relying Party

  • OP: OpenID Provider

5. Protocol Flow

Self-Issued OpenID Provider Request is an OpenID Connect Authentication Request that results in an End-user providing ID Token to the Relying Party through the Self-Issued OP. ID Token MAY include attested claims about the End-user.

+------+                                           +----------------+
|      |                                           |                |
|      |--(1) Self-Issued OpenID Provider Request->|                |
|      |     (Authentication Request)              |                |
|      |       +----------+                        |                |
|      |       |          |                        |                |
|      |       | End-User |                        |                |
|  RP  |       |          |<-(2) AuthN & AuthZ---->| Self-Issued OP |
|      |       |          |                        |                |
|      |       +----------+                        |                |
|      |                                           |                |
|      |<-(3) Self-Issued OpenID Provider Response-|                |
|      |      (Self-Issued ID Token)               |                |
|      |                                           |                |
+------+                                           +----------------+
Figure 1: Self-Issued Op Protocol Flow

6. Discovery and Negotiation

6.1. Self-Issued OpenID Provider Discovery

When the End-user first interacts with the RP there are no established means to signal where to direct the request for an available Self-Issued OP application. Even if possible, such signals may be susceptible to fingerprinting and passive tracking of the End-user.

The RP is therefore responsible for selecting where to direct the request URL. When the RP wants to support the End-user's choice to select from multiple possible Self-Issued OP applications, it MAY present a static list of the available choices. This is very similar to the process of supporting multiple different social networks.

Alternatively the RP MAY belong to at least one trust framework. The trust framework is then responsible for hosting a public website that maintains the latest platform specific metadata for all supported Self-Issued OP applications, known as app-link or universal link at the time of publication. The RP forms the request URL to that shared website and any of the supported installed applications will instead be launched and given the request to process. If none are available, the website will be displayed with the static list for the End-user to choose from to install or use.

The trust framework MAY be operated by just one RP, but due to the required maintenance of every application's metadata (which may change frequently) this burden SHOULD be shared across multiple RPs. The same trust framework MAY also be used to host metadata about the supported RPs such that the Self-Issued OP applications can verify the origin of the incoming request as part of the framework as well.

The legacy usage of custom protocol schemas such as openid: as a way to invoke any installed Self-Issued OP is NOT RECOMMENDED due to the security issues (see (invocation-using-custom-schema) in Privacy Considerations section).

6.1.1. Self-Issued OpenID Provider Discovery Metadata

If the input identifier for the discovery process contains the domain self-issued.me, dynamic discovery is not performed. Instead, then the following static configuration values are used:

  • authorization_endpoint

    • REQUIRED. MUST include openid:, could also include additional custom schema.

  • issuer

    • REQUIRED. MUST be https://self-issued.me/v2

  • responsetypessupported

    • REQUIRED. MUST be id_token

  • scopes_supported

    • REQUIRED. A JSON array of strings representing supported scopes. Valid values include openid, profile, email, address, and phone.

  • subjecttypessupported

    • REQUIRED. A JSON array of strings representing supported subject types. Valid values include pairwise and public.

  • idtokensigningalgvalues_supported

    • REQUIRED. ID token signing alg values supported. Valid values include RS256, ES256, ES256K, and EdDSA.

  • requestobjectsigningalgvalues_supported

    • REQUIRED. Request object signing alg values supported. Valid values include none, RS256, ES256, ES256K, and EdDSA.

The following is a non-normative example of the supported Self-issued OP Discovery metadata values:

  {
   "authorization_endpoint":
    "openid:",
   "issuer":
    "https://self-issued.me/v2",
   "response_types_supported":
    ["id_token"],
   "scopes_supported":
    ["openid", "profile", "email", "address", "phone"],
   "subject_types_supported":
    ["pairwise"],
    "id_token_signing_alg_values_supported":
    ["ES256", "ES256K"],
   "request_object_signing_alg_values_supported":
    ["ES256", "ES256K"]
  }

6.2. Relying Party Registration

Relying Party must communicate which metadata parameters it supports. If Self-Issued OP and RP mutually support a compatible set of parameters, Self-Issued OP flow continues. If they do not, Self-Issued OP returns an error. Metadata parameters should preferrably be sent by reference as a URI, but when RP cannot host a webserver, they can be sent by value.

OpenID Connect defines the following negotiation parameters to enable Relying Party to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration:

registration OPTIONAL. This parameter enables RP Registration Metadata to be passed in a single, self-contained parameter. The value is a JSON object containing RP Registration Metadata values.

registration_uri OPTIONAL. This parameter enables RP Registration Metadata to be passed by reference, rather than by value. The request_uri value is a URL using the https scheme referencing a resource containing RP Negotiation Metadata values.

RP MUST use either of there parameters, but if one of these parameters is used, the other MUST NOT be used in the same request.

RP Negotiation metadata values are defined in Section 4.3 and Section 2.1 of the OpenID Connect Dynamic RP Registration 1.0 [OpenID.Registration] specification.

If Self-Issued OP supports the same parameters, Self-Issued OpenID Provider flow continues, if Self-Issued OP does not support, it returns an error.

If no error is returned, the RP must proceed as if it had obtained the following Client Registration Response:

  • client_id

    • redirect_uri value of the Client.

  • clientsecretexpires_at

Metadata parameters should preferably be sent by reference as a URI using registration_uri parameter, but when RP cannot host a webserver, metadata parameters should be sent by value using registration parameter.

registration and registration_uri parameters SHOULD NOT be used when the OP is not a Self-Issued OP.

6.2.1. Passing Relying Party Registration Metadata by Value

The registration SIOP Request parameter enables RP Registration Metadata to be passed in a single, self-contained parameter.

The registration parameter value is represented in an OAuth 2.0 request as a UTF-8 encoded JSON object (which ends up being form-urlencoded when passed as an OAuth parameter). When used in a Request Object value, per Section 6.1, the JSON object is used as the value of the registration member.

6.2.2. Passing Relying Party Registration Metadata by Reference

The registration_uri SIOP Request parameter enables RP Registration Metadata to be passed by reference.

This parameter is used identically to the request parameter, other than that the Relying Party registration metadata value is retrieved from the resource at the specified URL, rather than passed by value.

The contents of the resource referenced by the URL MUST be a RP Registration Metadata Object. The scheme used in the registration_uri value MUST be https. The request_uri value MUST be reachable by the Self-Issued OP, and SHOULD be reachable by the RP.

6.2.3. Relying Party Registration Metadata Values

This extension defines the following RP Registration Metadata values, used by the RP to provide information about itself to the Self-Issued OP:

  • subjectidentifiertypes_supported

    • REQUIRED. A JSON array of strings representing supported subject identifier types. Valid values include jkt and did.

  • didmethodssupported

    • OPTIONAL. A JSON array of strings representing supported DID methods. Valid values must take the value of Method Name in Chapter 9 of [did-spec-registries], such as did:peer: RP can indicate support for any DID method by omitting did_methods_supported, while including did in `subjectidentifiertypes_supported'.

Other registration parameters defined in [OpenID.Registration] could be used. Examples are explanatory parameters such as policyuri, tosuri, and logouri. If the RP uses more than one Redirection URI, the redirecturis parameter would be used to register them. Finally, if the RP is requesting encrypted responses, it would typically use the jwksuri, idtokenencryptedresponsealg and idtokenencryptedresponse_enc parameters.

Registration parameter may include decentralized identifier of the RP.

The following is a non-normative example of the supported RP Registration Metadata Values:

  {
   "subject_identifier_types_supported":
    ["did", "jkt"],
    "did_methods_supported":
    ["did:key:", "did:example:"]
  }

6.3. Sub Types

A sub type is used by Self-Issued OP to advertise which types of identifiers are supported for the sub claim. Two types are defined by this specification:

  • jkt

    • JWK Thumbprint Subject sub type. When this subject sub type is used, the sub claim value MUST be the base64url encoded representation of the thumbprint of the key in the sub_jwk claim [RFC7638], and sub_jwk MUST be included in the Self-Issed OP response.

  • did

    • Decentralized Identifier sub type. When this subject type is used, the sub value MUST be a DID defined in [DID-CORE], and sub_jwk MUST NOT be included in the Self-Issed OP response. The subject type MUST be cryptographicaly verified against the resolved DID Document as defined in Self-Issued OP Validation.

NOTE: Consider adding a subject type for OpenID Connect Federation entity statements.

6.4. Relying Party Registration Metadata Error Response

This extension defines the following error codes that MUST be returned when Self-Issued OP does not support all of the Relying Party Registration metadata values received from the Relying Party in the registration parameter:

  • did_methods_not_supported

    • The Self-Issued OP does not support all of the DID methods included in did_methods_supported parameter.

  • subject_identifier_types_not_supported

    • The Self-Issued OP does not support all of the subject identifier types included in subject_identifier_types_supported parameter.

  • credential_formats_not_supported

    • The Self-Issued OP does not support all of the credential formats included in credential_formats_supported parameter.

  • value_not_supported

    • The Self-Issued OP does not support more than one of the RP Registration Metadata values defined in Section 4.3. When not supported metadata values are DID methods, subject identifier types, or credential formats, more specific error message must be used.

  • invalid_registration_uri

    • The registration_uri in the Self-Issued OpenID Provider request returns an error or contains invalid data.

  • invalid_registration_object

    • The registration parameter contains an invalid RP Registration Metadata Object.

Error response must be made in the same manner as defined in Section 3.1.2.6.

7. Identifier Portability and Verifiable Presentation Support

8. Self-Issued OpenID Provider Request

The RP sends the Authentication Request to the Authorization Endpoint with the following parameters:

When request or request_uri parameters are NOT present, registration or registration_uri parameters MUST be present in the request. When request or request_uri parameters are present, registration or registration_uri parameters MUST be included in either of those parameters.

Since it is an Implicit Flow response, nonce Claim MUST be present.

Other parameters MAY be sent. Note that all Claims are returned in the ID Token.

The entire URL MUST NOT exceed 2048 ASCII characters.

The following is a non-normative example HTTP 302 redirect response by the RP, which triggers the User Agent to make an Authentication Request to the Self-Issued OP (with line wraps within values for display purposes only):

  HTTP/1.1 302 Found
  Location: openid://?
    response_type=id_token
    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &registration=%7B%22logo_uri%22%3A%22https%3A%2F%2F
      client.example.org%2Flogo.png%22%7D

9. Self-Issued OpenID Provider Response

Self-Issued OpenID Provider Response is returned when Self-Issued OP supports all of the Relying Party Registration metadata values received from the Relying Party in the registration parameter. If even one of the Relying Party Registration Metadata Values is not supported, Self-Issued OP MUST return an error according to Section 4.4.

The response contains an ID Token and, if applicable, further response parameters as defined in extensions. As an example, the response MAY also include a VP token as defined in [OIDC4VP].

This extension defines the following claims to be included in the ID token for use in Self-Issued OpenID Provider Responses:

Whether the Self-Issued OP is a mobile client or a web client, response is the same as the normal Implicit Flow response with the following refinements. Since it is an Implicit Flow response, the response parameters will be returned in the URL fragment component, unless a different Response Mode was specified.

  1. The iss (issuer) Claim Value is https://self-issued.me/v2.

  2. The sub (subject) Claim value is either the base64url encoded representation of the thumbprint of the key in the sub_jwk Claim or a decentralized identifier.

  3. When sub Claim value is the base64url encoded representation of the thumbprint, a sub_jwk Claim is present, with its value being the public key used to check the signature of the ID Token.

  4. No Access Token is returned for accessing a UserInfo Endpoint, so all Claims returned MUST be in the ID Token.

9.1. Verifiable Presentation Support

Self-Issued OP and the RP that wish to support request and presentation of Verifiable Presentations MUST be compliant with OpenID Connect for Verifiable Presentations [OIDC4VP] and W3C Verifiable Credentials Specification [VC-DATA-MODEL].

Verifiable Presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs). [VC-DATA-MODEL]

10. Self-Issued ID Token Validation

See [OIDC4VP] on how to support multiple credential formats such as JWT and Linked Data Proofs.

To validate the ID Token received, the RP MUST do the following:

  1. The Relying Party (RP) MUST validate that the value of the iss (issuer) Claim is https://self-issued.me. If iss contains a different value, the ID Token is not Self-Issued, and instead it MUST be validated according to Section 3.1.3.

  2. The RP MUST validate that the aud (audience) Claim contains the value of the redirect_uri that the RP sent in the Authentication Request as an audience.

  3. The RP MUST validate the signature of the ID Token. When sub type isjkt, validation is done according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header, using the key in the sub_jwk Claim. When sub type isdid, validation is done using the key derived as a result of DID Resolution as defined in [DID-CORE]. The key is a bare key in JWK format (not an X.509 certificate value) when sub type isjkt or may be another key format when sub type is did.

  4. Default alg value is RS256. It MAY also be ES256, ES256K or EdDSA.

  5. The RP MUST validate thesub value. When sub type isjkt, the RP MUST validate that the sub claim value equals to the base64url encoded representation of the thumbprint of the key in the sub_jwk Claim, as specified in Section 6 of [OpenID]. When sub type is did, the RP MUST validate that sub claim value equals to the key in the verification method property of the DID Document. Since DID Document can contain mulitple keys, the validation MUST be performed against the key identified by the kid in the header. DID Document MUST be obtained by resolving decentralized identifier included in the sub claim.

  6. The current time MUST be before the time represented by the exp Claim (possibly allowing for some small leeway to account for clock skew). The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is RP specific.

  7. The RP MUST validate that a nonce Claim is present and is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is RP specific.

The following is a non-normative example of a base64url decoded Self-Issued ID Token (with line wraps within values for display purposes only):

  {
   "iss": "https://self-issued.me/v2",
   "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
   "aud": "https://client.example.org/cb",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB"
    }
&#12288;}

11. Cross Device SIOP

This section describes how SIOP is used in cross device scenarios. In contrast to on device scenarios, neither RP nor SIOP can communicate to each other via HTTP redirects through an user agent. The flow is therefore modfied as follows:

  1. The RP prepares a SIOP request and renders it as a QR code.

  2. The user scans the QR code with her smartphone's camera app.

  3. The standard mechanisms for invoking the SIOP are used on the smartphone (based on the openid custom scheme).

  4. The SIOP processes the authentication request.

  5. Upon completion of the authentication request, the SIOP directly sends a HTTP POST request with the authentication response to an endpoint exposed by the RP.

Note: the request in step 5 is not a form post request where the SIOP would respond to a user agent with a form, which automatically triggers a POST request to the RP. The SIOP sends this request directly to the RP's endpoint.

11.1. Authentication Request

The cross device authentication request differs from the on-device variant as defined in Section 8 as follows:

  • This specification introduces a new response mode post in accordance with [OIDM]. This response mode is used to request the SIOP to deliver the result of the authentication process to a certain endpoint. The additional parameter response_mode is used to carry this value.

  • This endpoint the SIOP shall deliver the authentication result to is conveyed in the standard parameter redirect_uri.

  • The RP MUST ensure the nonce value used for a particular transaction is available at this endpoint for security checks.

Here is an example of an authentication request URL:

    openid://?
    response_type=id_token
    &response_mode=post
    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &registration=%7B%22subject_identifier_types_supported%22:%5B%22jkt%22%5D,
    %22id_token_signing_alg_values_supported%22:%5B%22RS256%22%5D%7D

Note: Such an authentication request might result in a large QR code, especially when including a claims parameter and extensive registration data. A RP MAY consider to use a request_uri in such a case.

11.2. Authentication Response

The SIOP sends the authentication response to the endpoint passed in the redirect_uri authentication request parameter using a HTTP POST request using "application/x-www-form-urlencoded" encoding. The authentication response contains the parameters as defined in Section 9.

Here is an example:

  POST /cb HTTP/1.1
  Host: client.example.com
  Content-Type: application/x-www-form-urlencoded

  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso

11.3. ID Token Validation

The RP MUST perform all the check as defined in Section 10

Additionally, the RP MUST check whether the nonce claim value provided in the ID Token is known to the RP and was not used before in an authentication response.

12. References

The following is a non-normative example of an ID token containing a verifiable presentation (with line wraps within values for display purposes only):

  {
   "iss": "https://self-issued.me/v2",
   "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
   "aud": "https://client.example.org/cb",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB"
    },
    "verifiable_presentations":[
      {
         "format":"vp_jwt",
         "presentation":"ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0="
      }
   ],
&#12288;}

Note: Further processing steps are required if the authentication response contains verifiable presentations - see [OIDC4VP].

12.1. Security Considerations

12.1.1. Invocation using Custom Schema {invocation-using-custom-schema}

Usage of custom schemas as a way to invoke a Self-Issued OP may lead to phishing attacks and undefined behavior.

Custom schema is a mechanism offered by Mobile Operating System providers. If an application developer registers custom schema with the application, that application will be invoked when a request containing custom schema is received by the device.

Any malicious app can register the custom schema already used by another app, imitate the user interface and impersonate a good app.

When more than one Self-issued OP with the same custom schema has been installed on one device, the behavior of Self-Issued OP is undefined.

12.2. Privacy Considerations

12.2.1. Selective disclosure and un-linkable presentations

Usage of decentralized identifiers does not automatically prevent possible RP correlation. If a status check of the presentation is done, IdP / SIOP correlation can occur.

Consider supporting selective disclosure and un-linkable presentations using zero-knowledge proofs or single-use credentials instead of traditional correlatable signatures.

13. References

14. Relationships to other documents

The scope of this draft was an extention to OpenID Connect Chapter 7 Self-Issued OpenID Provider. However, some sections of it could become applicable more generally to the entire OpenID Connect specification.

15. Normative References

[did-spec-registries]
Steele, O. and M. Sporny, "Decentralized Identifiers (DIDs) v1.0", , <https://w3c.github.io/did-spec-registries/#did-methods>.
[DID-CORE]
Sporny, M., Guy, A., Sabadello, M., and D. Reed, "Decentralized Identifiers (DIDs) v1.0", , <https://www.w3.org/TR/did-core/>.
[OpenID]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", , <http://openid.net/specs/openid-connect-core-1_0.html>.
[OIDC4VP]
Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. Looker, "OpenID Connect Core 1.0 incorporating errata set 1", , <https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html>.
[OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1", , <https://openid.net/specs/openid-connect-registration-1_0.html>.

Appendix A. IANA Considerations

TBD

Appendix B. Notices

Copyright (c) 2021 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.

Appendix C. Document History

[[ To be removed from the final specification ]]

-04

* added cross device flow
* clarified sub handling for did-based sub and sub_jwk
* Revising of introductory text and scope of SIOPv2
* corrected typos and reworked registration example data

-03

* sub_jwk made optional for sub type DID and mandatory for subtype jwk thumbprint
* Added text that nonce is mandatory
* Replaced vp claim with reference to OIDC4VP draft
* Adopted SIOP chooser as SIOP Discovery
* Deprecated openid:// for SIOP Discovery as not recommended
* Clarified Discovery and Registration metadata
* Formatted Normative Reference Section to mmarkdown

-02
 * Converted into mmarkdown

-01
 * Version proposed for working group adoption

Authors' Addresses

Kristina Yasuda
Microsoft
Michael B. Jones
Microsoft
Tobias Looker
Mattr