Skip to main content
European CommissionEBSI European Blockchain
Get Help
Select the Environment you want to work withEnvironment:
warning icon

This API is being released as part of an upcoming version.

The upcoming version is not backward compatible with the current stable version. You can find the details of the upcoming release and affected endpoints in the change log. Please contact eu-ebsi@ec.europa.eu if this upcoming release might cause a high impact on either an ongoing development or a piloting demonstration.

OpenID Provider Metadata

Last updated on 
GET 
/authorisation/v4/.well-known/openid-configuration

Exposes the configuration of the OpenID Provider

Request​

Responses​

OpenID Provider Metadata

Schema
    issuer URIrequired

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

    Note: issuer refers to OpenID Connect issuer or the Authorization Server and not to the Verifiable Credential issuer.

    Ref: OIDC

    authorization_endpoint URIrequired

    REQUIRED. URL of the OP's OAuth 2.0 Authorization Endpoint [OpenID.Core].

    Note: The Authorization Endpoint is a conceptual entity and does not have a physical manifestation. The Token Endpoint and Presentation Endpoint serve as the primary components responsible for providing user authorization.

    Ref: OIDC

    token_endpoint URIrequired

    CONDITIONAL. URL of the OP's OAuth 2.0 Token Endpoint.

    Note: This endpoint is REQUIRED unless implicit flow is used.

    Ref: OIDC

    presentation_definition_endpoint URI

    OPTIONAL. URL of the OP's presentation definitions endpoint.

    Non-standard (yet). Used in EBSI.

    jwks_uri URIrequired

    REQUIRED. URL of the authorization server's JWK Set [JWK] document. The referenced document contains the signing key(s) the client uses to validate signatures from the authorization server. This URL MUST use the "https" scheme. The JWK Set MAY also contain the server's encryption key(s), which are used by clients to encrypt requests to the server. When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.

    Ref: OIDC

    scopes_supported string[]required

    REQUIRED (by SIOP v2). JSON array containing a list of the OAuth 2.0 [RFC6749] scope values that this server supports. The server MUST support the openid scope value. Servers MAY choose not to advertise some supported scope values even when this parameter is used, although those defined in [OpenID.Core] SHOULD be listed, if supported.

    MUST contain 'openid'

    Ref:

    response_types_supported string[]required

    REQUIRED (by SIOP v2). JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports. The array values used are the same as those used with the "response_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].

    If SIOP v2 is used: MUST be id_token

    Ref:

    response_mode_supported string[]

    OPTIONAL. JSON array containing a list of the OAuth 2.0 response_mode values that this OP supports, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. If omitted, the default for Dynamic OpenID Providers is ["query", "fragment"].

    MUST be 'query'

    Ref:

    grant_types_supported string[]

    JSON array containing a list of the OAuth 2.0 grant type values that this authorization server supports. The array values used are the same as those used with the "grant_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]. If omitted, the default value is "["authorization_code", "implicit"]".

    Ref:

    subject_types_supported string[]required

    REQUIRED. JSON array containing a list of the Subject Identifier types that this OP supports. Valid types include pairwise and public.

    MUST be ['public']

    Ref:

    id_token_signing_alg_values_supported string[]required

    REQUIRED. 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 [JWT].

    The algorithm ES256 MUST be included. Ref:

    request_object_signing_alg_values_supported string[]

    Possible values: [none, ES256, RS256, ES256K, EdDSA]

    OPTIONAL. 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 Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter).

    Servers MUST support none and ES256.

    Ref:

    request_parameter_supported Supported Request Parameters

    OPTIONAL. Boolean value specifying whether the OP supports use of the request parameter, with true indicating support. If omitted, the default value is false.

    EBSI: MUST be true

    Ref:

    token_endpoint_auth_methods_supported string[]

    Possible values: [private_key_jwt]

    JSON array containing a list of client authentication methods supported by this token endpoint

    MUST contain 'private_key_jwt'

    request_authentication_methods_supported object

    OPTIONAL. A JSON Object defining the client authentications supported for each endpoint. The endpoint names are defined in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters]. Other endpoints and authentication methods are possible if made recognizable according to established standards and not in conflict with the operating principles of this specification. In OpenID Connect Core, no client authentication is performed at the authentication endpoint. Instead, because the request itself is authenticated. What it amounts to is that the OP maps information in the request (like the redirect_uri) to information it has gained on the client through static or dynamic registration. If the map is successful, the request can be processed. If the RP uses Automatic Registration, as defined in Section 10.1, the OP has no prior knowledge of the RP. Therefore, the OP must start by gathering information about the RP using the process outlined in Section 6. Once it has the RP's metadata, the OP can verify the request in the same way as if it had known the RP's metadata beforehand. To make the request verification more secure, we demand the use of a client authentication or verification method that proves that the RP is in possession of a key that appears in the RP's metadata.

    Reference: https://openid.net/specs/openid-connect-federation-1_0.html#name-op-metadata

    authorization_endpoint string[]

    Possible values: [request_object]

    MUST be present. The value MUST be 'request_object'

    vp_formats_supported object

    REQUIRED. An object containing a list of key value pairs, where the key is a string identifying a credential format supported by the AS. Valid credential format identifiers values are defined in Annex E of [OpenID.VCI]. Other values may be used when defined in the profiles of this specification.

    jwt_vp object
    alg_values_supported string[]

    Possible values: [ES256]

    An object where the value is an array of case sensitive strings that identify the cryptographic suites that are supported. Cryptosuites for Verifiable Presentations. MUST contain ES256

    jwt_vc object
    alg_values_supported string[]

    Possible values: [ES256]

    An object where the value is an array of case sensitive strings that identify the cryptographic suites that are supported. Cryptosuites for Verifiable Credentials in jwt_vc_json, json_vc_json-ld, jwt_vp_json, json_vp_json-ld formats should use algorithm names defined in IANA JOSE Algorithms Registry. Cryptosuites for Verifiable Credentials in ldp_vc and ldp_vp format should use signature suites names defined in Linked Data Cryptographic Suite Registry. Cryptosuites for Verifiable Credentials in mso_mdoc format should use signature suites names defined in ISO/IEC 18013-5:2021. Parties using other credential formats will need to agree upon the meanings of the values used, which may be context-specific.

    MUST contain ES256

    subject_syntax_types_supported URI[]

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

    Reference: https://openid.net/specs/openid-connect-self-issued-v2-1_0.html

    MUST contain: did:ebsi, did:key

    subject_trust_frameworks_supported string[]

    REQUIRED. A JSON array of supported trust frameworks.

    MUST contain: 'ebsi'

    id_token_types_supported string[]

    Possible values: [subject_signed_id_token]

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

      MUST be subject_signed_id_token

Loading...