Self-Issued OpenID Provider v2

1.1. Terms and Definitions

Common terms in this document come from four primary sources: [OpenID.Core], [VC-DATA] and [DID-Core]. 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) used by the End-users to prove control over a cryptographically verifiable identifier¶

• Self-Issued OP Request¶

  • Request to a Self-Issued OP from an RP¶

• Self-Issued OP Response¶

  • Response to an RP from a Self-Issued OP¶

• Self-Issued ID Token¶

  • ID Token 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 OP 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.¶

• Verifiable Credential (VC)¶

  • A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects. See [VC-DATA].¶

1.2. Abbreviations

• OP: OpenID Provider¶

• RP: Relying Party¶

• Self-Issued OP or SIOP: Self-Issued OpenID Provider¶

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

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. 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 [OIDC4VP].¶

2.4. Sharing Claims (e.g. VC) 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 usually issued by different authorities, and are hard to verify in a digital form. A Self-issued OP directly representing the user may have access to a greater set of such information for example in the format of Verifiable 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 claims from multiple sources, potentially in multiple formats, 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.5. 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.¶

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

3.1. In Scope

This specification extends the OpenID Connect implicit flow in the following ways:¶

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

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

• RP Registration: mechanisms for how the RPs register metadata such as supported functionalities with the Self-Issued OP, registration parameters and RP Metadata Registration Methods.¶

• Self-Issued ID Token: defines additional claims and processing requirements of ID Tokens issued by Self-Issued OPs¶

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

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

3.2. Out of Scope

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

3.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.2.2.¶

• Added support for Cross-Device Self-Issued OP model. See Section 5.¶

• Extended Relying Party Registration mechanisms to support pre-registration and dynamic registration for not-pre-registered RPs. See Section 9.¶

• Added support for Dynamic Self-Issued OpenID Provider Discovery. See Section 8.2.¶

• Added support for claimed URLs (universal links, app links) in addition to the custom URL schemas as Self-Issued OP authorization_endpoint. See Section 8.2.1.¶

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

8.1. Static Self-Issued OpenID Provider Discovery Metadata

When the RP does not have the means to pre-obtain Self-Issued OP Discovery Metadata, dynamic discovery is not performed. Instead, the following static configuration values are used.¶

{
  "authorization_endpoint": "openid:",
  "issuer": "https://self-issued.me/v2",
  "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"
  ]
}

Editor's Note: Discuss whether subject_syntax_types_supported should be defined in static Self-Issued OP Discovery Metadata.¶

RP MUST use custom URI scheme openid: as the authorization_endpoint to construct the request. Self-Issued OPs invoked via openid: MUST set issuer identifier, or iss Claim in the ID Token to https://self-issued.me/v2.¶

Note that the request using custom URI scheme openid: will open only Self-Issued OPs as native apps and does not support Self-Issued OPs as Web applications. For other types of Self-Issued OP deployments, the usage of the Universal Links, or App Links is recommended as explained in Section 8.2.1.¶

8.2. Dynamic Self-Issued OpenID Provider Discovery Metadata

As an alternative mechanism to the Section 8.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.¶

• authorization_endpoint¶

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

• 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 be 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 {#sub-syntax-type}. When Subject Syntax Type is JWK Thumbprint, valid value is urn:ietf:params:oauth:jwk-thumbprint defined in [JWK-Thumbprint-URI]. 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.¶

Note: Need to confirm Mandatory to Implement alg values that we want to explicitly support for id_token_signing_alg_values_supported and request_object_signing_alg_values_supported¶

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. Issuer identifier of the Self-Issued OP, or iss Claim in the ID Token, MUST be the issuer identifier specified in the Discovery Metadata.¶

When dynamic Self-Issued OpenID Provider discovery has been used, an additional i_am_siop Claim MUST be included in the ID Token as a way for the RP to determine if the ID Token has been issued by the Self-Issued OP.¶

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

{
  "authorization_endpoint": "siop:", //can be a universal link/app link
  "issuer": "https://client.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"
  ]
}

9.1. Pre-Registered Relying Party

When the RP has pre-registered with the Self-Issued OP using [OpenID.Registration] or out-of-band mechanisms, client_id MUST equal to the client identifier the RP has obtained from the Self-Issued OP during pre-registration, and registration nor registration_uri parameters MUST NOT be present in the Self-Issued OP Request. When the Self-Issued OP Request is signed, the public key for verification MUST be obtained during the pre-registration process.¶

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 Authentication Request to the Self-Issued OP (with line wraps within values for display purposes only):¶

  HTTP/1.1 302 Found
  Location:  https://client.example.org/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

9.2. Non-Pre-Registered Relying Party

When the RP has not pre-registered and has to dynamically register with the Self-Issued OP, the registration mechanism depends on whether the Self-Issued OP Request is signed or not.¶

When the Self-Issued OP request is not signed, all registration parameters MUST be passed using registration parameter defined in Section 9.2.1, or using out-of-band mechanism. In this case, client_id MUST equal redirect_uri.¶

When the Self-Issued OP request is signed, the public key to verify the signature is obtained by resolving Relying Party's client_id. Depending on the Relying Party Metadata Resolution Method used, the rest of the RP Registration metadata SHOULD be included either in the registration parameter inside the Self-Issued OP request, or in the Entity Statement as defined in OpenID Federation 1.0 Automatic Registration. In this case, client_id MUST NOT equal redirect_uri.¶

registration parameters MUST NOT include redirect_uris to prevent attackers from inserting malicious Redirection URI. If registration parameter includes redirect_uris, Self-Issued OP MUST ignore it and only use redirect_uri directly supplied in the Self-Issued OP request.¶

Note that in Self-Issued OP protocol flow, no registration response is returned. A successful authentication response implicitly indicates that the registration parameters were accepted.¶

  HTTP/1.1 302 Found
  Location: https://client.example.org/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
    &registration=%7B%22subject_syntax_types_supported%22%3A
    %5B%22urn%3Aietf%3Aparams%3Aoauth%3Ajwk-thumbprint%22%5D%2C%0A%20%20%20%20
    %22id_token_signing_alg_values_supported%22%3A%5B%22RS256%22%5D%7D

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

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

"client_id": "did:example:EiDrihTRe0GMdc3K16kgJB3Xbl9Hb8oqVHjzm6ufHcYDGA"

  openid://?
    scope=openid%20profile
    &response_type=id_token
    &client_id=did%3Aexample%3AEiDrihTRe0GMdc3K16kgJB3Xbl9Hb8oqVHjzm6ufHcYDGA
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &claims=...
    &registration=%7B%22subject_syntax_types_supported%22%3A
    %5B%22did%3Aexample%22%5D%2C%0A%20%20%20%20
    %22id_token_signing_alg_values_supported%22%3A%5B%22ES256%22%5D%7D
    &nonce=n-0S6_WzA2Mj

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

10.1. Cross-Device Self-Issued OpenID Provider Request

The cross-device authentication request differs from the same-device variant as defined in Section 10 as follows:¶

• This specification introduces a new response mode 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 OP Request URL in a cross-device protocol flow Section 5:¶

  openid://?
    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
    &claims=...
    &registration=%7B%22subject_syntax_types_supported%22%3A
    %5B%22urn%3Aietf%3Aparams%3Aoauth%3Ajwk-thumbprint%22%5D%2C%0A%20%20%20%20
    %22id_token_signing_alg_values_supported%22%3A%5B%22ES256%22%5D%7D
    &nonce=n-0S6_WzA2Mj

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

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 using a request_uri in such a case.¶

11.1. Cross-Device Self-Issued OpenID Provider Response

The Self-Issued OP 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 11.¶

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

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

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

  id_token=...

11.2. 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: user cancelled the authentication request from the RP.¶

• registration_value_not_supported: the Self-Issued OP does not support some Relying Party Registration metadata 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_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.¶

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

12.1. 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 determine whether the ID Token has been issued by the Self-Issued OP. When static Self-Issued OP Discovery metadata has been used, iss MUST be https://self-issued.me/v2. When Self-Issued OP Discovery metadata has been obtained dynamically, an additional i_am_siop Claim MUST be present in the ID Token and iss MUST exactly match the issuer identifier specified in the Self-Issued OP Discovery Metadata MUST be included in the ID Token as a way for the RP to determine if the, when dynamic Self-Issued OpenID Provider discovery has been used.¶

2. The RP MUST validate that the aud (audience) Claim contains the value of the client_id that the RP sent in the Authentication 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 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 11. 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 Authentication Request. The Client MUST check the nonce value for replay attacks. The precise method for detecting replay attacks is RP specific.¶

12.2. Cross-Device Self-Issued ID Token Validation

The RP MUST perform all the check as defined in Section 12.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 authentication 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": "https://siop.example.com",
  "sub": "did:example:NzbLsXh8uDCcd6MNwXF4W7noWXFZAfHkxZsRGC9Xs",
  "aud": "https://client.example.org/cb",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "presentation_submission": {
    "id": "Selective disclosure example presentation",
    "definition_id": "Selective disclosure example",
    "descriptor_map": [
      {
        "id": "ID Card with constraints",
        "format": "ldp_vp",
        "path": "$",
        "path_nested": {
          "format": "ldp_vc",
          "path": "$.verifiableCredential[0]"
        }
      }
    ]
  }
}

Further processing steps are required if the authentication response contains presentation_submission as in the example above - see [OIDC4VP].¶

14.1. Handling End-User Data

Using the mechanisms described in this specification and [OIDC4VP], 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.¶

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

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

A known attack in cross-device Self-Issued OP is an authentication request replay attack, where a victim is tricked to send a response to an authentication 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 authentication 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 authentication 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 authentication 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 Verfiable 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 devices that does not show a browser with a URL bar.¶

• The authentication request can be made short-lived. An attacker would have to request a new authentication 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.¶

Implementors 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 authentication response comes from the same browser where the authentication 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.¶

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

Usage of private-use URI schemes such as openid:, 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 custom scheme is received by the device. If no available application supports the custom URI scheme, the platform or browser will typically generate a modal error and present it to the End-User.¶

Implementors 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 authentication 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 a 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].¶

15.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 selective disclosure and unlinkable presentations using zero-knowledge proofs or single-use credentials instead of traditional correlatable signatures.¶

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