Self-Issued OpenID Provider v2 - draft 13

1.1. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶

1.2. Notable Differences between OpenID Connect Core and Self-Issued OP Models

In the traditional OpenID Connect model, when an OP acts as an ID Token issuer, it is common for the OP to have a legal stake with the RPs and a reputation-based stake with both RPs and End-Users to provide correct information. In the Self-Issued OP model, the RP's trust relationship is directly with the End-User. The Self-Issued OP allows the End-User to authenticate towards the RP with an identifier controlled by the End-User instead of an identifier assigned to the End-User by a third-party provided OP. An End-User controlled identifier might be a public key fingerprint or a Decentralized Identifier (see [DID-Core]). This changes the trust model and the way signatures of the Self-Issued ID Tokens are validated in comparison to the traditional OpenID Connect model.¶

In traditional OpenID Connect, the ID Token is signed by the OP as an entity, identified by the iss claim. The RP uses this identifier to obtain the key material to validate the ID Token's signature. This signature ensures the data is attested by the OP the RP trusts for that purpose and it also is an attestation of what service produced the ID Token (since both are the same entity).¶

In the Self-Issued OP case, the ID Token is self-signed with a private key under the user's control, identified by the sub claim. The RP uses this identifier to obtain the key material to validate the ID Token's signature. Unlike traditional OpenID Connect, this signature can no longer be used to cryptographically validate the software or service that created the ID Token. Self-issued ID Token can be detected when the iss value is set to the user identifier conveyed in the sub Claim, because from a conceptual perspective, the issuer of the ID Token is the user. This also aligns Self-Issued OP with the way self-signed certificates and W3C Verifiable Presentations handle subject and issuer of such certificates and assertions, respectively.¶

Because a Self-Issued OP within the End-User’s control does not have the legal, reputational trust of a traditional OP, claims about the End-User (e.g., birthdate) included in a Self-Issued ID Token, are by default self-asserted and non-verifiable. A Self-Issued OP can also present cryptographically verifiable claims issued by the third-party sources trusted by the RP, as defined in separate specifications such as [OpenID4VP] or Aggregated and Distributed Claims in Section 5.6.2 of [OpenID.Core].¶

1.3. Terms and Definitions

This specification uses the terms "Authorization Request", "Authorization Response", "Authorization Server", "Client", "Client Identifier", "Response Type", and "Token Response" defined by OAuth 2.0 [RFC6749], the terms "End-User", "Entity", "Request Object", and "Request URI" as defined by OpenID Connect Core [OpenID.Core], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [RFC7519], the term "JOSE Header" and the term "Base64url Encoding" defined by JSON Web Signature (JWS) [RFC7515], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses].¶

This specification also defines the following terms. In the case where a term has a definition that differs, the definition below is authoritative.¶

Self-Issued OpenID Provider (Self-Issued OP):

An OpenID Provider (OP) to prove control over a cryptographically Verifiable Identifier¶

Self-Issued Request:

Request to a Self-Issued OP from an RP¶

Self-Issued Response:

Response to an RP from a Self-Issued OP¶

Self-Issued ID Token:

ID Token signed using the key material controlled by the End-User. It is issued by a Self-Issued OP.¶

Cryptographically Verifiable Identifier:

An identifier that is either based upon or resolves to cryptographic key material that can be used to verify a signature on the ID Token or the Self-Issued Request.¶

Trust Framework:

A legally enforceable set of specifications, rules, and agreements that govern a multi-party system established for a common purpose, designed for conducting specific types of transactions among a community of participants, and bound by a common set of requirements, as defined in OIX.¶

Wallet:

Entity that receives, stores, presents, and manages Credentials and key material of the End-User. There is no single deployment model of a Wallet: Credentials and keys can both be stored/managed locally by the End-User, or by using a remote self-hosted service, or a remote third party service. In the context of this specification, the Wallet acts as an Self-Issued OpenID Provider towards the RP.¶

1.4. Abbreviations

• OP: OpenID Provider¶
• RP: Relying Party¶
• Self-Issued OP or SIOP: Self-Issued OpenID Provider¶

2.1. In Scope

This specification extends the OpenID Connect Core in the following ways:¶

• Invocation of a Self-Issued OP: mechanisms for how the RP invokes/opens a Self-Issued OP.¶

• Obtaining Self-Issued OP Metadata (Static and Dynamic Discovery): mechanisms for how the RP discovers Self-issued OP's metadata such as authorization endpoint.¶

• Obtaining RP Metadata: mechanisms for how the Self-Issued OPs obtain RP metadata both with or without RP pre-registering with the Self-Issued OP.¶

• Self-Issued ID Token: defines additional claims and processing requirements of ID Tokens issued by Self-Issued OPs. An ID Token is self-issued if the values of the iss and the sub claims are the same.¶

• Support for Self-Asserted Claims: transporting claims in a Self-Issued ID Token that are not verifiable by the RP.¶

• Support for Cryptographically Verifiable Identifiers: an identifier that is either based upon or can be resolved to cryptographic key material and is used by the Self-Issued OPs in the sub Claim of the ID Token to prove possession of the cryptographic key used to sign the ID Token. Types of such identifiers are defined in this specification as Subject Syntax Types.¶

2.2. Out of Scope

The following are considered out of scope of this document.¶

2.3. Relationship with Section 7 of [OpenID.Core] Self-Issued OpenID Provider

This specification extends Section 7 of [OpenID.Core] Self-Issued OpenID Provider in the following ways:¶

• Added support for Decentralized Identifiers defined in [DID-Core] as Cryptographically Verifiable Identifiers in addition to the JWK thumbprint defined in Self-Issued OP v2. See Section 8.¶
• Added support for Cross-Device Self-Issued OP model. See Section 4.¶
• Extended mechanisms how not-pre-registered RPs can pass their metadata in the Authorization Request. See Section 7.¶
• Added support for Dynamic Self-Issued OpenID Provider Discovery. See Section 6.1.¶
• Added support for claimed URLs (universal links, app links) in addition to the custom URL scheme as Self-Issued OP authorization_endpoint. See Section 6.2.¶
• Added support to use of any OpenID Connect flow for Self-Issued OPs and Dynamic Client Registration.¶

Note that while this specification extends the original Section 7 of [OpenID.Core] Self-Issued OpenID Provider, some sections of it could be applicable more generally to the entire OpenID Connect Core specification.¶

6.1. Dynamic Discovery of Self-Issued OpenID Provider Metadata

As an alternative mechanism to the Section 15.1, the RP can pre-obtain Self-Issued OP Discovery Metadata prior to the transaction, either using [OpenID.Discovery], or out-of-band mechanisms.¶

How the RP obtains Self-Issued OP's Issuer Identifier is out of scope of this specification. The RPs MAY skip Section 2 of [OpenID.Discovery].¶

When [OpenID.Discovery] is used, the RP MUST obtain Self-Issued OP metadata from a JSON document that Self-Issued OP made available at the path formed by concatenating the string /.well-known/openid-configuration to the Self-Issued OP's Issuer Identifier.¶

Note that contrary to [OpenID.Discovery], jwks_uri parameter MUST NOT be present in Self-Issued OP Metadata. If it is, the RP MUST ignore it and use the sub Claim in the ID Token to obtain signing keys to validate the signatures from the Self-Issued OpenID Provider.¶

These metadata values are used by the Self-Issued OP:¶

• authorization_endpoint¶

  • REQUIRED. URL of the Self-Issued OP used by the RP to perform Authentication of the End-User. Can be custom URL scheme, or Universal Links/App links. See Section 6.2.¶

• issuer¶

  • REQUIRED. URL using the https scheme with no query or fragment component that the Self-Issued OP asserts as its Issuer Identifier. MUST be identical to the iss Claim value in ID Tokens issued from this Self-Issued OP.¶

• response_types_supported¶

  • REQUIRED. A JSON array of strings representing supported response types. MUST include id_token.¶

• scopes_supported¶

  • REQUIRED. A JSON array of strings representing supported scopes. MUST support the openid scope value.¶

• subject_types_supported¶

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

• id_token_signing_alg_values_supported¶

  • REQUIRED. A JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [RFC7519]. Valid values include RS256, ES256, ES256K, and EdDSA.¶

• request_object_signing_alg_values_supported¶

  • REQUIRED. A JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for Request Objects, which are described in Section 6.1 of [OpenID.Core]. Valid values include none, RS256, ES256, ES256K, and EdDSA.¶

• subject_syntax_types_supported¶

  • REQUIRED. A JSON array of strings representing URI scheme identifiers and optionally method names of supported Subject Syntax Types defined in Section 8. When Subject Syntax Type is JWK Thumbprint, a valid value is urn:ietf:params:oauth:jwk-thumbprint defined in [RFC9278]. When Subject Syntax Type is Decentralized Identifier, valid values MUST be a did: prefix followed by a supported DID method without a : suffix. For example, support for the DID method with a method-name "example" would be represented by did:example. Support for all DID methods listed in Section 13 of [DID_Specification_Registries] is indicated by sending did without any method-name.¶

• id_token_types_supported:¶

  • OPTIONAL. A JSON array of strings containing the list of ID Token types supported by the OP, the default value is attester_signed_id_token. The ID Token types defined in this specification are:¶

    • subject_signed_id_token: Self-Issued ID Token, i.e. the ID Token is signed with key material under the End-User's control.¶
    • attester_signed_id_token: the ID Token is issued by the party operating the OP, i.e. this is the classical ID Token as defined in [OpenID.Core].¶

Other Discovery parameters defined in Section 3 of [OpenID.Discovery] MAY be used.¶

The RP MUST use the authorization_endpoint defined in Self-Issued OP Discovery Metadata to construct the request.¶

The following is a non-normative example of a Self-Issued OP metadata obtained dynamically:¶

{
  "authorization_endpoint": "https://wallet.example.com",
  "issuer": "https://example.org",
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "subject_types_supported": [
    "pairwise"
  ],
  "id_token_signing_alg_values_supported": [
    "ES256K",
    "EdDSA"
  ],
  "request_object_signing_alg_values_supported": [
    "ES256K",
    "EdDSA"
  ],
  "subject_syntax_types_supported": [
    "urn:ietf:params:oauth:jwk-thumbprint",
    "did:key"
  ],
  "id_token_types_supported": [
    "subject_signed_id_token"
  ]
}

6.2. Choice of authorization_endpoint

As the authorization_endpoint of a Self-Issued OP, the use of Universal Links or App Links is RECOMMENDED over the use of custom URL schemes. See Section 13.4 for details.¶

7.1. Pre-Registered Relying Party

See Section X.X of [OpenID4VP].¶

The following is a non-normative example of a same-device request when the RP is pre-registered with the Self-Issued OP. HTTP 302 redirect request by the RP triggers the User Agent to make an Authorization Request to the Self-Issued OP (with line wraps within values for display purposes only):¶

  HTTP/1.1 302 Found
  Location:  https://wallet.example.com/universal-link?
    response_type=id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &nonce=n-0S6_WzA2Mj

7.2. Non-Pre-Registered Relying Party

When the RP has not pre-registered, it may pass its metadata to the Self-Issued OP in the Authorization Request. This mechanism is different from registration (Dynamic Client Registration or an out-of-band pre-registration) since Self-Issued OP does not return Client ID to the RP that the RP can re-use at the Self-Issued OP.¶

No registration response is returned. A successful Authorization Response implicitly indicates that the client metadata parameters were accepted.¶

"client_id": "https://client.example.org"

"client_id": "did:example:EiDrihTRe0GMdc3K16kgJB3Xbl9Hb8oqVHjzm6ufHcYDGA"

siopv2://?
  client_id=did%3Aexample%3AEiDri
  &request_uri=https%3A%2F%2Fclient.example.org%2Frequest%2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

{
  "alg": "ES256",
  "kid": "did:example:EiDri#sign1",
  "typ": "JWT"
}.
{
  "client_id": "did:example:EiDri",
  "scope": "openid profile",
  "response_type": "id_token",
  "redirect_uri": "https://client.example.org/cb",
  "client_metadata": {
    "subject_syntax_types_supported": [
      "did:example"
    ],
    "id_token_signed_response_alg": "ES256"
  },
  "nonce": "n-0S6_WzA2Mj"
}.[signature]

7.3. Relying Party Client Metadata parameter

As defined in Section X.X of [OpenID4VP].¶

The following is a non-normative example of an unsigned same-device request when the RP is not pre-registered with the Self-Issued OP. HTTP 302 redirect request by the RP triggers the User Agent to make an Authorization Request to the Self-Issued OP (with line wraps within values for display purposes only):¶

  HTTP/1.1 302 Found
  Location: https://wallet.example.com/universal-link?
    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
    &nonce=n-0S6_WzA2Mj
    &client_metadata=%7B%22subject_syntax_types_supported%22%3A
    %5B%22urn%3Aietf%3Aparams%3Aoauth%3Ajwk-thumbprint%22%5D%2C%0A%20%20%20%20
    %22id_token_signed_response_alg%22%3A%22RS256%22%7D

7.4. Relying Party Metadata Error Response

When the Self-Issued OP receives a pre-registered Client ID of Section 7.1, but client_metadata or client_metadata_uri parameters of Section 7.2 are also present, the Self-Issued OP MUST return an error. When the Self-Issued OP receives a Client ID of Section 7.2 that it has cached following one of the methods defined in Section 7.2, it does not return an error.¶

Self-Issued OPs compliant with this specification MUST NOT proceed with the transaction when pre-registered client metadata has been found based on the Client ID, but client_metadata parameter has also been present.¶

Usage of client_metadata or client_metadata_uri parameters with Client ID that the Self-Issued OP might be seeing for the first time is mutualy exclusive with the registration mechanism where the Self-Issued OP assigns Client ID to the RP after receiving the RP's metadata.¶

7.5. Relying Party Metadata Values

This extension defines the following RP parameter value, used by the RP to provide information about itself to the Self-Issued OP:¶

• subject_syntax_types_supported¶

  • REQUIRED. A JSON array of strings representing URI scheme identifiers and optionally method names of supported Subject Syntax Types defined in Section 8. When Subject Syntax Type is JWK Thumbprint, a valid value is urn:ietf:params:oauth:jwk-thumbprint defined in [RFC9278]. When Subject Syntax Type is Decentralized Identifier, valid values MUST be a did: prefix followed by a supported DID method without a : suffix. For example, support for the DID method with a method-name "example" would be represented by did:example. Support for all DID methods is indicated by sending did without any method-name.¶

Other client metadata parameters defined in [OpenID.Registration] MAY be used. Examples are explanatory parameters such as policy_uri, tos_uri, and logo_uri. If the RP uses more than one Redirection URI, the redirect_uris parameter would be used to register them. Finally, if the RP is requesting encrypted responses, it would typically use the jwks_uri, id_token_encrypted_response_alg and id_token_encrypted_response_enc parameters.¶

The following is a non-normative example of the supported RP parameter Values:¶

{
  "subject_syntax_types_supported": [
    "urn:ietf:params:oauth:jwk-thumbprint",
    "did:example",
    "did:key"
  ]
}

9.1. aud of a Request Object

When an RP is sending a Request Object in a Self-Issued Request as defined in [RFC9101], the aud Claim value depends on whether the recipient of the request can be identified by the RP or not:¶

• The aud Claim MUST equal to the issuer Claim value, when Dynamic Self-Issued OP Discovery is performed.¶
• The aud Claim MUST be "https://self-issued.me/v2", when Static Self-Issued OP Discovery Metadata is used.¶

9.2. Cross-Device Self-Issued OpenID Provider Request

The cross-device Authorization Request differs from the same-device variant (with response type id_token) as defined in Section 9 as follows:¶

• This specification introduces a new response mode direct_post in accordance with [OAuth.Responses]. This response mode is used to request the Self-Issued OP to deliver the result of the authentication process to a certain endpoint using the HTTP POST method. The additional parameter response_mode is used to carry this value.¶
• This endpoint to which the Self-Issued OP shall deliver the authentication result is conveyed in the standard parameter redirect_uri.¶

Self-Issued OP is on a different device than the one on which the End-User’s user interactions are occurring.¶

The following is a non-normative example of a Self-Issued Request URL in a cross-device protocol flow Section 4:¶

  siopv2://?
    scope=openid%20profile
    &response_type=id_token
    &client_id=https%3A%2F%2Fclient.example.org%2Fpost_cb
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fpost_cb
    &response_mode=post
    &client_metadata=%7B%22subject_syntax_types_supported%22%3A
    %5B%22urn%3Aietf%3Aparams%3Aoauth%3Ajwk-thumbprint%22%5D%2C%0A%20%20%20%20
    %22id_token_signed_response_alg%22%3A%22ES256%22%7D
    &nonce=n-0S6_WzA2Mj

Note that the Authorization Request might only include request parameters and not be targeted to a particular authorization_endpoint, in which case, the End-User must use a particular Self-Issued OP application to scan the QR code with such request.¶

Such an Authorization Request might result in a large QR code, especially when including extensive client_metadata. An RP MAY consider using a request_uri in such a case.¶

10.1. Self-Issued OpenID Provider Response (Authorization Code Flow)

The following is an informative example of a Self-Issued Response for the authorization code flow (response_type=code):¶

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "expires_in": 3600,
   "id_token": "..."
  }

Note: the SIOP MAY also provide End-User claims to the RP via the Userinfo endpoint.¶

10.2. Cross-Device Self-Issued OpenID Provider Response

The Self-Issued OP sends the Authorization Response to the endpoint passed in the redirect_uri Authorization Request parameter using an HTTPS POST request using "application/x-www-form-urlencoded" encoding. The Authorization Response contains the parameters as defined in Section 10.¶

The Self-Issued OP MUST NOT follow redirects on this request.¶

The following is an informative example of a Self-Issued Response in a cross-device protocol flow: Section 4:¶

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

  id_token=...

10.3. Self-Issued OpenID Provider Error Response

The error response must be made in the same manner as defined in Section 3.1.2.6 of [OpenID.Core].¶

In addition to the error codes defined in Section 4.1.2.1 of OAuth 2.0 and Section 3.1.2.6 of [OpenID.Core], this specification also defines the following error codes:¶

• user_cancelled: End-User cancelled the Authorization Request from the RP.¶
• client_metadata_value_not_supported: the Self-Issued OP does not support some Relying Party parameter values received in the request.¶
• subject_syntax_types_not_supported: the Self-Issued OP does not support any of the Subject Syntax Types supported by the RP, which were communicated in the request in the subject_syntax_types_supported parameter.¶
• invalid_client_metadata_uri: the client_metadata_uri in the Authorization Request returns an error or contains invalid data.¶
• invalid_client_metadata_object: the client_metadata parameter contains an invalid RP parameter Object.¶

Other error codes MAY be used.¶

Note that HTTP error codes do not work in the cross-device Self-Issued OP protocol flows.¶

The following is a non-normative example of an error response in the same-device Self-Issued OP protocol flow:¶

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    error=invalid_request
    &error_description=Unsupported%20response_type%20value

11.1. Self-Issued ID Token Validation

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

1. The Relying Party (RP) MUST determine whether the ID Token has been issued by the Self-Issued OP. The ID Token is self-issued if the iss Claim and the sub Claim have the same value. If both values differ, the ID Token MUST be processed as defined in [OpenID.Core], section 3.2.2.11..¶
2. The RP MUST validate that the aud (audience) Claim contains the value of the Client ID that the RP sent in the Authorization Request as an audience. When the request has been signed, the value might be an HTTPS URL, or a Decentralized Identifier.¶
3. The RP MUST identify which Subject Syntax Type is used based on the URI of the sub Claim. Valid values defined in this specification are urn:ietf:params:oauth:jwk-thumbprint for JWK Thumbprint Subject Syntax Type and did: for Decentralized Identifier Subject Syntax Type.¶
4. The RP MUST validate the signature of the ID Token. When Subject Syntax Type is JWK Thumbprint, validation is done according to JWS [RFC7515] using the algorithm specified in the alg header parameter of the JOSE Header, using the key in the sub_jwk Claim. The key MUST be a bare key in JWK format (not an X.509 certificate value). The RP MUST validate that the algorithm is one of the allowed algorithms (as in id_token_signing_alg_values_supported). When Subject Syntax Type is Decentralized Identifier, validation is performed against the key obtained from a DID Document. DID Document MUST be obtained by resolving a Decentralized Identifier included in the sub Claim using DID Resolution as defined by a DID Method specification of the DID Method used. Since verificationMethod property in the DID Document may contain multiple public key sets, public key identified by a key identifier kid in a Header of a signed ID Token MUST be used to validate that ID Token.¶
5. The RP MUST validate the sub Claim value. When Subject Syntax Type is JWK Thumbprint, the RP MUST validate that the sub Claim value equals the base64url encoded representation of the thumbprint of the key in the sub_jwk Claim, as specified in Section 10. When Subject Syntax Type is Decentralized Identifier, the RP MUST validate that the sub Claim value equals the id property in the DID Document.¶
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 Authorization Request. The Client MUST check the nonce value for replay attacks. The precise method for detecting replay attacks is RP specific.¶

Any claim in the Self-Issued ID Token is considered to be self-attested. Verifying attestation by a third party requires additional artifacts and processing steps - see [OpenID4VP].¶

11.2. Cross-Device Self-Issued ID Token Validation

The RP MUST perform all the check as defined in Section 11.1.¶

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 Authorization Response.¶

The following is a non-normative example of a base64url decoded Self-Issued ID Token body when the dynamic Self-Issued OP Discovery and Decentralized Identifier Subject Syntax Type are used (with line wraps within values for display purposes only):¶

{
  "iss": "did:example:NzbLsXh8uDCcd6MNwXF4W7noWXFZAfHkxZsRGC9Xs",
  "sub": "did:example:NzbLsXh8uDCcd6MNwXF4W7noWXFZAfHkxZsRGC9Xs",
  "aud": "https://client.example.org/cb",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970
}

13.1. Handling End-User Data

Using the mechanisms described in this specification and [OpenID4VP], data about the End-User can be transported to the Relying Party in different ways. It is important that implementers take into consideration the specific security properties associated with the mechanisms.¶

13.2. RP and Self-Issued OP Metadata Integrity

The integrity and authenticity of Self-Issued OP and RP metadata is paramount for the security of the protocol flow. For example, a modified authorization_endpoint could be used by an attacker to launch phishing or mix-up-style attacks (see [I-D.oauth-security-topics]). A modified redirect_uri could be used by an attacker to gather information that can then be used in replay attacks. The provisions defined in this specification ensure the authenticity and integrity of the metadata if all checks (signature validation, etc.) are performed as described.¶

13.3. Usage of Cross-Device Self-Issued OP for Authentication

A known attack in cross-device Self-Issued OP is an Authorization Request replay attack, where a victim is tricked to send a response to an Authorization Request that an RP has generated for an attacker. In other words, the attacker would trick a victim to respond to a request that the attacker has generated for him/herself at a good RP, for example, by showing the QR code encoding the Authorization Request that would normally be presented on the RP's website on the attacker's website. In this case, the victim might not be able to detect that the request was generated by the RP for the attacker. (Note that the same attack applies when methods other than a QR code are used to encode the Authorization Request. For brevity, only the QR code method will be discussed in the following, but the same considerations apply to other transport methods as well.)¶

This attack is based on the fact that the Authorization Request is not tied to a specific channel, i.e., it can be used both in its original context (on the RP's website) as well as in a replay scenario (on the attacker's website, in an email, etc.). Such a binding cannot be established across devices with currently deployed technology. Therefore, in the cross-device protocol flow, the contents transported in the authentication (including any Verifiable Presentations) are not wrong, but do not necessarily come from the End-User the RP website thinks it is interacting with.¶

Implementers MUST take this fact into consideration when using cross-device Self-Issued OP. There are a number of measures that can be taken to reduce the risk of such an attack, but none of these can completely prevent the attack. For example:¶

• The Self-Issued OP can show the origin of the request (e.g., the domain where the response will be sent) and/or ask the End-User to confirm this origin. In an attack, this origin would be different from the attacker's origin where the QR code is displayed to the End-User. It cannot be expected that all End-Users will identify an attack in this way, but at least for some users it might help to detect the attack. Note that depending on the device on which the attacker is showing the QR code, there might be no indication of the origin, e.g., on a terminal device that does not show a browser with a URL bar.¶
• The Authorization Request can be made short-lived. An attacker would have to request a new Authorization Request (e.g., QR code) frequently and update it on its website as well. This requires more effort from the attacker.¶
• Self-Issued OP can warn the End-User when logging in at a new RP for the first time.¶

Implementers should be cautious when using cross-device Self-Issued OP model for authentication and should implement mitigations according to the desired security level.¶

This attack does not apply for the same-device Self-Issued OP protocol flows as the RP checks that the Authorization Response comes from the same browser where the Authorization Request was sent to. Same-device Self-Issued OP protocol flows therefore can be used for authentication, given all other security measures are put in place.¶

For more details on possible attacks and mitigations see [I-D.ietf-oauth-cross-device-security].¶

13.4. Invocation using Private-Use URI Schemes (Custom URL Schemes)

Usage of private-use URI schemes with a certain path such as siopv2://, also referred to as custom URL schemes, as a way to invoke a Self-Issued OP may lead to phishing attacks and undefined behavior, as described in [RFC8252].¶

Private-use URI schemes are a mechanism offered by mobile operating system providers. If an application developer registers a custom URL scheme with the application, that application will be invoked when a request containing the custom URL scheme is received by the device. If no available application supports the custom URL scheme, the platform or browser will typically generate a modal error and present it to the End-User.¶

Implementers are highly encouraged to explore other options before using private-use URI schemes due to the known security issues of such schemes, such as lack of controls to prevent unknown applications from attempting to service Authorization Requests. Any malicious app can register the custom scheme already used by another app, imitate the user interface and impersonate a good app.¶

The browser or operating system typically has a process by which native applications and websites can register support that one or more apps be called when an HTTPS URI is triggered in lieu of a system browser. This feature goes by several names including "App Links" and "Universal Links", and MAY be used to invoke an installed/registered Self-Issued OP. If no appropriate application has been rendered, the request for a Self-Issued OP will go to a browser, which MAY display additional information such as appropriate software options.¶

Further details are discussed in [app-2-app-sec].¶

13.5. Self-Issued OP Authorization Response Confidentiality

The Authorization Response MUST NOT leak to a party outside of the Self-Issued OP, the RP and the system browser participating in the protocol flow.¶

Implementers of Self-Issed OPs are encouraged to take operating system dependent measures to ensure that the Authorization Response is only passed to a legitimate system browser in the same-device protocol flow. If implementers wish to support native applications acting as an RP, they MAY alternatively invoke the RP application if the Self-Issed OP can verify the RP application to be legitimate.¶

Further details of application to application and application to web communication are discussed in [app-2-app-sec].¶

13.6. TLS Requirements

Implementations MUST follow [BCP195].¶

Whenever TLS is used, a TLS server certificate check MUST be performed, per [RFC6125].¶

14.1. Selective Disclosure and Unlinkable Presentations

Usage of decentralized identifiers does not automatically prevent possible RP correlation. If a status check of the presentation is done, Identity Provider / Self-Issued OP correlation can occur.¶

Consider supporting pairwise identifiers that are unique per RP.¶

15.1. Static Configuration Values of the Self-Issued OPs

This document lists profiles that define static configuration values of Self-Issued OPs and defines two sets of static configuration values for Self-Issued OPs as native apps that can be used by the RP when it is unable to perform dynamic discovery and is not using any of the profiles.¶

{
  "authorization_endpoint": "siopv2:",
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "subject_types_supported": [
    "pairwise"
  ],
  "id_token_signing_alg_values_supported": [
    "ES256"
  ],
  "request_object_signing_alg_values_supported": [
    "ES256"
  ],
  "subject_syntax_types_supported": [
    "urn:ietf:params:oauth:jwk-thumbprint"
  ],
  "id_token_types_supported": [
    "subject_signed_id_token"
  ]
}

{
  "authorization_endpoint": "openid:",
  "response_types_supported": [
    "vp_token",
    "id_token"
  ],
  "vp_formats_supported": {
    "jwt_vp": {
      "alg": ["ES256"]
    },
    "jwt_vc": {
      "alg": ["ES256"]
    }
  },
  "scopes_supported": [
    "openid"
  ],
  "subject_types_supported": [
    "pairwise"
  ],
  "id_token_signing_alg_values_supported": [
    "ES256"
  ],
  "request_object_signing_alg_values_supported": [
    "ES256"
  ],
  "subject_syntax_types_supported": [
    "urn:ietf:params:oauth:jwk-thumbprint"
  ],
  "id_token_types_supported": [
    "subject_signed_id_token"
  ]
}

15.2. Supporting Multiple Self-Issued OPs

When the RP wants to provide End-User choice to select from multiple possible Self-Issued OPs, it MAY present a static list of the supported options. This is similar to the process of supporting multiple different social networks represented as traditional OPs.¶

Note that if Self-Issued OP implementations belong to a trust framework, the trust framework may dictate a common authorization_endpoint for a set of implementations. If authorization_endpoint is pre-registered with the underlying browser or operating system, invocation of this endpoint that leads to prompting the End-User to select a Self-Issued OP is handled by the underlying browser or operating system.¶

15.3. Receiving Cross-Device Responses

In case of the cross-device flow, the Self-Issued OP will send the result as an HTTPS POST message to the RP. This requires connectivity between Self-Issued OP and RP. There are different ways this can be achieved. The RP may, for example, expose a suitable endpoint from their backend. Alternatively, it may employ a separate service able to receive and store such messages, where the RP then queries the Self-Issued OP responses.¶

D.1. Resilience against Sudden or Planned Hosted OP Unavailability

A hosted third-party provided OP'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. End-Users using Self-Issued OPs local to their environment, have lower chances of being simultaneously affected by such events.¶

D.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. 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.¶

D.3. Authentication and Presentations of User Claims without the involvement of the Issuer

The RP can directly receive the issuer-signed claims about the End-User from the Self-Issued OP, without talking to the Issuer. This prevents the Issuer from knowing where the End-User is presenting these issuer-signed claims. In this use-case, obtaining and potentially storing the issuer-signed credentials is the Self-Issued OP's responsibility using specifications such as [OpenID4VP].¶

D.4. Aggregation of Multiple Personas under One Self-Issued OP

End-Users often use several hosted OpenID Providers for different Relying Parties. Some of the reasons to do this is to separate a work-related persona from a personal persona or to prevent the RPs 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 forgotten 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.¶

D.5. Identifier Portability

With a hosted third-party provider, a user identifier used at the RP is assigned by the third-party, while with a Self-Issued OP, a user identifier can be created by an application locally controlled by the End-User. This would allow the End-User to maintain the relationship with the RP while minimizing the third-party influence, as long as the End-User can keep control of the Self-Issued identifier.¶

D.6. Cloud Wallet

End-Users may decide to store their credentials in a cloud wallet, in order to be able to access her existing credentials across devices without hazzle (e.g. no need to re-obtain credentials after changing phone). A cloud wallet is an applicatication that is not hosted entirely locally on the End-User's device, but has cloud-based components and is capable of hosting backend endpoints. Such a wallet can protect the user's credental on a high security level. It may, for example, utilize hardware security modules to protect the user's keys from cloning and replay. Since there is a backend involved and endpoints can be exposed, a cloud wallet can utilize the OpenID Connect authorization code flow, which allows verifier and wallet to mutually authenticate and exchange data via a direct TLS protected connection.¶

A cloud wallet may utilize a native user experience, it may also (in addition or exclusively) offer a web based experience, which can be used on any device without the need for an app installation. This also means such a wallet can always use the more secure on-device flow instead of the cross-device flow. End-User authentication can be implemented using roaming authenticators or a private protocol with an authentication app.¶