# --------------------------------------------------------------------------- # STET PSD2 - OAuth2 Technical Setup (Dynamic Client Registration, RFC 7591/7592) # # Source (official): https://www.stet.eu/assets/files/site/PSD2/1-5/TechnicalSetup_1.0.5_OAS2.yaml # Official version: 1.0.5 (STET publishes a single Technical Setup file shared # across every PSD2 API version) # Bundled with API: 1.6.3 # License: Creative Commons Attribution 3.0 France (CC BY 3.0 FR) # # Local modifications vs the official 1.0.5 file, to align with the client-metadata # table documented in this version's Framework (Part 1, OAuth2 technical setup): # - Added the `tls_client_auth_subject_dn` client-metadata field (Mandatory per the # Framework client-metadata table / RFC 8705); it is absent from the official 1.0.5 file. # - GrantTypes: replaced `password` with `ciba` to match this version's Framework # allowed grant types (the OAuth2 `password` flow was dropped in STET 1.6.x). # - Flagged `jwks_uri`, `software_id` and `software_version` as not used by # the STET API (x-not-used-by-stet): they are valid RFC 7591 client-metadata # fields, but the STET API ignores them and they no longer appear in the # Framework client-metadata table. (This is a usage restriction, NOT # deprecation — the fields remain valid in RFC 7591 itself.) # --------------------------------------------------------------------------- swagger: "2.0" info: version: 1.0.5 ### The [title] directive might be customized within each implementation title: Oauth2 Technical SETUP description: | Oauth2 Technical Setup according to RFC7591:RFC7592 - The client must present an eIDAS QWAC certificate during TLS negociation - The server will use this certificate to authenticate the client and check the client is allowed to process an OAUTH2 technical setup - However during the first registration the certificate check will be incomplete since it has not been registered yet. contact: name: STET url: https://www.stet.eu/en/psd2/ email: psd2@stet.eu license: name: Creative Commons Attribution 3.0 France (CC BY 3.0 FR) ### The [basePath] directive might be customized within each implementation basePath: /v1 schemes: - https consumes: - application/json paths: /register: post: operationId: registrationPost summary: Client Registration request description: | [From RFC7591] This operation registers a client with the authorization server. Theauthorization server assigns this client a unique client identifier, optionally assigns a client secret, and associates the metadata provided in the request with the issued client identifier. The request includes any client metadata parameters being specified for the client during the registration. The authorization server MAY provision default values for any items omitted in the client metadata. To register, the client or developer sends an HTTP POST to the client registration endpoint with a content type of "application/json". The HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON object and all requested client metadata values as top-level members of that JSON object. parameters: - $ref: '#/parameters/RegistrationRequestParameter' - $ref: '#/parameters/DigestHeader' - $ref: '#/parameters/SignatureHeader' - $ref: "#/parameters/Correlation" responses: "201": description: Created schema: $ref: '#/definitions/RegistrationRecord' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. "400": $ref: '#/responses/400' "401": $ref: '#/responses/401' "403": $ref: '#/responses/403' "405": $ref: '#/responses/405' "406": $ref: '#/responses/406' "408": $ref: '#/responses/408' "429": $ref: '#/responses/429' "500": $ref: '#/responses/500' "501": $ref: '#/responses/501' "503": $ref: '#/responses/503' /register/{clientId}: get: operationId: registrationGet summary: Retrieve the actual registration for a given client_id description: | [From RFC7592] To read the current configuration of the client on the authorization server, the client makes an HTTP GET request to the client configuration endpoint, authenticating with its registration access token. ### Modified for CR384: Remove DIGEST HEADER for GET and DELETE request parameters: - $ref: '#/parameters/ClientIdParameter' - $ref: '#/parameters/SignatureHeader' - $ref: "#/parameters/Correlation" responses: "200": description: Retrieval of the registration schema: $ref: '#/definitions/RegistrationRecord' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. "400": $ref: '#/responses/400' "401": $ref: '#/responses/401' "403": $ref: '#/responses/403' "405": $ref: '#/responses/405' "406": $ref: '#/responses/406' "408": $ref: '#/responses/408' "429": $ref: '#/responses/429' "500": $ref: '#/responses/500' "501": $ref: '#/responses/501' "503": $ref: '#/responses/503' put: operationId: registrationPut summary: Update the actual registration for a given client_id description: | [From RFC7592] To update a previously registered client’s registration with an authorization server, the client makes an HTTP PUT request to the client configuration endpoint with a content type of "application/json". The HTTP entity payload is a JSON [RFC7159] document consisting of a JSON object and all parameters as top-level members of that JSON object. This request is authenticated by the registration access token issued to the client. This request MUST include all client metadata fields as returned to the client from a previous registration, read, or update operation. The updated client metadata fields request MUST NOT include the "registration_access_token", "registration_client_uri", "client_secret_expires_at", or "client_id_issued_at" fields described in Section 3. Valid values of client metadata fields in this request MUST replace, not augment, the values previously associated with this client. Omitted fields MUST be treated as null or empty values by the server, indicating the client’s request to delete them from the client’s registration. The authorization server MAY ignore any null or empty value in the request just as any other value. The client MUST include its "client_id" field in the request, and it MUST be the same as its currently issued client identifier. If the client includes the "client_secret" field in the request, the value of this field MUST match the currently issued client secret for that client. The client MUST NOT be allowed to overwrite its existing client secret with its own chosen value. For all metadata fields, the authorization server MAY replace any invalid values with suitable default values, and it MUST return any such fields to the client in the response. parameters: - $ref: '#/parameters/ClientIdParameter' - $ref: '#/parameters/RegistrationRecordparameter' - $ref: '#/parameters/DigestHeader' - $ref: '#/parameters/SignatureHeader' - $ref: "#/parameters/Correlation" responses: "200": description: Retrieval of the updated registration schema: $ref: '#/definitions/RegistrationRecord' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. "400": $ref: '#/responses/400' "401": $ref: '#/responses/401' "403": $ref: '#/responses/403' "405": $ref: '#/responses/405' "406": $ref: '#/responses/406' "408": $ref: '#/responses/408' "429": $ref: '#/responses/429' "500": $ref: '#/responses/500' "501": $ref: '#/responses/501' "503": $ref: '#/responses/503' delete: operationId: registrationDelete summary: Delete the actual registration for a given client_id description: | [From RFC7592] To deprovision itself on the authorization server, the client makes an HTTP DELETE request to the client configuration endpoint. This request is authenticated by the registration access token issued to the client. ### Modified for CR384: Remove DIGEST HEADER for GET and DELETE request parameters: - $ref: '#/parameters/ClientIdParameter' - $ref: '#/parameters/SignatureHeader' - $ref: "#/parameters/Correlation" responses: "204": description: No content. Deletion of the relevant registration headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. "400": $ref: '#/responses/400' "401": $ref: '#/responses/401' "403": $ref: '#/responses/403' "405": $ref: '#/responses/405' "406": $ref: '#/responses/406' "408": $ref: '#/responses/408' "429": $ref: '#/responses/429' "500": $ref: '#/responses/500' "501": $ref: '#/responses/501' "503": $ref: '#/responses/503' responses: 204: description: No content. headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 400: description: Invalid status value schema: $ref: '#/definitions/ErrorModel_400' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 401: description: Unauthorized, authentication failure. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 403: description: Forbidden, authentication successful but access to resource is not allowed. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 404: description: Not found, no request available. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 405: description: Method Not Allowed. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 406: description: Not Acceptable. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 408: description: Request Timeout. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 409: description: | Conflict. The request could not be completed due to a conflict with the current state of the target resource. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 429: description: Too many requests. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response Warning: type: string description: | Warning header. This header can be used by the server to inform the client of a deprecated entry-point through the value "299" value and a descriptive message. 500: description: Internal server error. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response 501: description: | Not Implemented. This code should be used when the entry point is implemented but cannot provide a result, given the context. When the entry point is not implemented at all, HTTP400 will be returned. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response 503: description: Service unavailable. schema: $ref: '#/definitions/ErrorModel' headers: X-Request-ID: type: string description: | Correlation header to be set in a request and retrieved in the relevant response definitions: ErrorModel: description: Generic error report structure type: object required: - status - message properties: timestamp: description: current timestamp type: string format: date-time status: description: HTTP error code type: integer format: int32 error: description: HTTP error text type: string maxLength: 140 message: description: HTTP textual reason phrase type: string maxLength: 140 path: description: Relevant path that was used type: string maxLength: 140 example: { "timestamp" : "2018-03-30T16:06:27.499+0000", "status" : 400, "error" : "Bad Request", "message" : "Missing parameter of type String", "path" : "/v1/registration" } ErrorModel_400: description: Generic error report structure type: object required: - error properties: error: description: HTTP error text type: string enum: - invalid_redirect_uri - invalid_client_metadata - invalid_software_statement - unapproved_software_statement error_description: description: HTTP textual reason phrase type: string maxLength: 140 example: { "error": "invalid_redirect_uri", "error_description": "The redirection URI http://sketchy.example.com is not allowed by this server." } JsonWebKey: description: | A JWK is a JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value. This JSON object MAY contain whitespace and/or line breaks before or after any JSON values or structural characters, in accordance with Section 2 of RFC 7159 [RFC7159]. This document defines the key parameters that are not algorithm specific and, thus, common to many keys. type: object required: - kty properties: kty: description: | The "kty" (key type) parameter identifies the cryptographic algorithm family used with the key, such as "RSA" or "EC". "kty" values should either be registered in the IANA "JSON Web Key Types" registry established by [JWA] or be a value that contains a Collision- Resistant Name. The "kty" value is a case-sensitive string. This member MUST be present in a JWK. A list of defined "kty" values can be found in the IANA "JSON Web Key Types" registry established by [JWA]; the initial contents of this registry are the values defined in Section 6.1 of [JWA]. The key type definitions include specification of the members to be used for those key types. Members used with specific "kty" values can be found in the IANA "JSON Web Key Parameters" registry established by Section 8.1. type: string use: description: | The "use" (public key use) parameter identifies the intended use of the public key. The "use" parameter is employed to indicate whether a public key is used for encrypting data or verifying the signature on data. Values defined by this specification are: o "sig" (signature) o "enc" (encryption) Other values MAY be used. The "use" value is a case-sensitive string. Use of the "use" member is OPTIONAL, unless the application requires its presence. When a key is used to wrap another key and a public key use designation for the first key is desired, the "enc" (encryption) key use value is used, since key wrapping is a kind of encryption. The "enc" value is also to be used for public keys used for key agreement operations. Additional "use" (public key use) values can be registered in the IANA "JSON Web Key Use" registry established by Section 8.2. Registering any extension values used is highly recommended when this specification is used in open environments, in which multiple organizations need to have a common understanding of any extensions used. However, unregistered extension values can be used in closed environments, in which the producing and consuming organization will always be the same. type: string key_ops: description: | The "key_ops" (key operations) parameter identifies the operation(s) for which the key is intended to be used. The "key_ops" parameter is intended for use cases in which public, private, or symmetric keys may be present. Its value is an array of key operation values. Values defined by this specification are: o "sign" (compute digital signature or MAC) o "verify" (verify digital signature or MAC) o "encrypt" (encrypt content) o "decrypt" (decrypt content and validate decryption, if applicable) o "wrapKey" (encrypt key) o "unwrapKey" (decrypt key and validate decryption, if applicable) o "deriveKey" (derive key) o "deriveBits" (derive bits not to be used as a key) (Note that the "key_ops" values intentionally match the "KeyUsage" values defined in the Web Cryptography API [W3C.CR-WebCryptoAPI-20141211] specification.) Other values MAY be used. The key operation values are casesensitive strings. Duplicate key operation values MUST NOT be present in the array. Use of the "key_ops" member is OPTIONAL, unless the application requires its presence. Multiple unrelated key operations SHOULD NOT be specified for a key because of the potential vulnerabilities associated with using the same key with multiple algorithms. Thus, the combinations "sign" with "verify", "encrypt" with "decrypt", and "wrapKey" with "unwrapKey" are permitted, but other combinations SHOULD NOT be used. Additional "key_ops" (key operations) values can be registered in the IANA "JSON Web Key Operations" registry established by Section 8.3. The same considerations about registering extension values apply to the "key_ops" member as do for the "use" member. The "use" and "key_ops" JWK members SHOULD NOT be used together; however, if both are used, the information they convey MUST be consistent. Applications should specify which of these members they use, if either is to be used by the application. type: array items: type: string alg: description: | The "alg" (algorithm) parameter identifies the algorithm intended for use with the key. The values used should either be registered in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA] or be a value that contains a Collision-Resistant Name. The "alg" value is a case-sensitive ASCII string. Use of this member is OPTIONAL. type: string kid: description: | The "kid" (key ID) parameter is used to match a specific key. This is used, for instance, to choose among a set of keys within a JWK Set during key rollover. The structure of the "kid" value is unspecified. When "kid" values are used within a JWK Set, different keys within the JWK Set SHOULD use distinct "kid" values. (One example in which different keys might use the same "kid" value is if they have different "kty" (key type) values but are considered to be equivalent alternatives by the application using them.) The "kid" value is a case-sensitive string. Use of this member is OPTIONAL. When used with JWS or JWE, the "kid" value is used to match a JWS or JWE "kid" Header Parameter value. type: string x5u: description: | The "x5u" (X.509 URL) parameter is a URI [RFC3986] that refers to a resource for an X.509 public key certificate or certificate chain [RFC5280]. The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 [RFC5280] in PEM-encoded form, with each certificate delimited as specified in Section 6.1 of RFC 4945 [RFC4945]. The key in the first certificate MUST match the public key represented by other members of the JWK. The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. Use of this member is OPTIONAL. While there is no requirement that optional JWK members providing key usage, algorithm, or other information be present when the "x5u" member is used, doing so may improve interoperability for applications that do not handle PKIX certificates [RFC5280]. If other members are present, the contents of those members MUST be semantically consistent with the related fields in the first certificate. For instance, if the "use" member is present, then it MUST correspond to the usage that is specified in the certificate, when it includes this information. Similarly, if the "alg" member is present, it MUST correspond to the algorithm specified in the certificate. type: string x5c: description: | The "x5c" (X.509 certificate chain) parameter contains a chain of one or more PKIX certificates [RFC5280]. The certificate chain is represented as a JSON array of certificate value strings. Each string in the array is a base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER [ITU.X690.1994] PKIX certificate value. The PKIX certificate containing the key value MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. The key in the first certificate MUST match the public key represented by other members of the JWK. Use of this member is OPTIONAL. As with the "x5u" member, optional JWK members providing key usage, algorithm, or other information MAY also be present when the "x5c" member is used. If other members are present, the contents of those members MUST be semantically consistent with the related fields in the first certificate. type: array items: type: string x5t: description: | The "x5t" (X.509 certificate SHA-1 thumbprint) parameter is a base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate [RFC5280]. Note that certificate thumbprints are also sometimes known as certificate fingerprints. The key in the certificate MUST match the public key represented by other members of the JWK. Use of this member is OPTIONAL. As with the "x5u" member, optional JWK members providing key usage, algorithm, or other information MAY also be present when the "x5t" member is used. If other members are present, the contents of those members MUST be semantically consistent with the related fields in the referenced certificate. type: string x5t#S256: description: | The "x5t#S256" (X.509 certificate SHA-256 thumbprint) parameter is a base64url-encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate [RFC5280]. Note that certificate thumbprints are also sometimes known as certificate fingerprints. The key in the certificate MUST match the public key represented by other members of the JWK. Use of this member is OPTIONAL. As with the "x5u" member, optional JWK members providing key usage, algorithm, or other information MAY also be present when the "x5t#S256" member is used. If other members are present, the contents of those members MUST be semantically consistent with the related fields in the referenced certificate. type: string JsonWebKeySet: description: | A JWK Set is a JSON object that represents a set of JWKs. The JSON object MUST have a "keys" member, with its value being an array of JWKs. This JSON object MAY contain whitespace and/or line breaks. The member names within a JWK Set MUST be unique; JWK Set parsers MUST either reject JWK Sets with duplicate member names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript]. Additional members can be present in the JWK Set; if not understood by implementations encountering them, they MUST be ignored. Parameters for representing additional properties of JWK Sets should either be registered in the IANA "JSON Web Key Set Parameters" registry established by Section 8.4 or be a value that contains a Collision-Resistant Name. Implementations SHOULD ignore JWKs within a JWK Set that use "kty" (key type) values that are not understood by them, that are missing required members, or for which values are out of the supported ranges. type: object required: - keys properties: keys: description: | The value of the "keys" parameter is an array of JWK values. By default, the order of the JWK values within the array does not imply an order of preference among them, although applications of JWK Sets can choose to assign a meaning to the order for their purposes, if desired. type: array items: $ref: '#/definitions/JsonWebKey' RedirectUris: description: Array of redirection URIs for use in redirect-based flows type: array items: type: string TokenEndpointAuthMethod: description: | Requested authentication method for the token endpoint. * "none": The client is a public client as defined in OAuth 2.0, Section 2.1, and does not have a client secret. * "client_secret_post": The client uses the HTTP POST parameters as defined in OAuth 2.0, Section 2.3.1. * "client_secret_basic": The client uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1. * "tls_client_auth": Indicates that client authentication to the authorization server will occur with mutual TLS utilizing the PKI method of associating a certificate to a client. STET API: only "tls_client_auth" can be used in order to comply with MTLS method used for PSD2 API. type: string enum: - none - client_secret_post - client_secret_basic - tls_client_auth TlsClientAuthSubjectDn: description: | Extension required by the STET PSD2 Framework (Part 1 - OAuth2 technical setup) and RFC 8705, but absent from the official 1.0.5 Technical Setup file. Indicates the certificate subject value that the authorization server is to expect when authenticating the respective client. An [RFC4514] string representation of the expected subject distinguished name of the certificate, which the OAuth client will use in mutual-TLS authentication. type: string GrantTypes: description: | Array of OAuth 2.0 grant type strings that the client can use at the token endpoint. These grant types are defined as follows: * "authorization_code": The authorization code grant type defined in OAuth 2.0, Section 4.1. * "implicit": The implicit grant type defined in OAuth 2.0, Section 4.2. * "password": The resource owner password credentials grant type defined in OAuth 2.0, Section 4.3. * "client_credentials": The client credentials grant type defined in OAuth 2.0, Section 4.4. * "refresh_token": The refresh token grant type defined in OAuth 2.0, Section 6. * "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer Token Grant Type defined in OAuth JWT Bearer Token Profiles [RFC7523]. * "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2.0 Bearer Assertion Grant defined in OAuth SAML 2 Bearer Token Profiles [RFC7522]. If the token endpoint is used in the grant type, the value of this parameter MUST be the same as the value of the "grant_type" parameter passed to the token endpoint defined in the grant type definition. Authorization servers MAY allow for other values as defined in the grant type extension process described in OAuth 2.0, Section 4.5. If omitted, the default behavior is that the client will use only the "authorization_code" Grant Type. STET API: allowed values are: * authorization_code * ciba * client_credentials * refresh_token type: array items: type: string enum: - authorization_code - implicit - ciba - client_credentials - refresh_token - urn:ietf:params:oauth:grant-type:jwt-bearer - urn:ietf:params:oauth:grant-type:saml2-bearer ResponseTypes: description: | Array of the OAuth 2.0 response type strings that the client can use at the authorization endpoint. These response types are defined as follows: * "code": The authorization code response type defined in OAuth 2.0, Section 4.1. * "token": The implicit response type defined in OAuth 2.0, Section 4.2. If the authorization endpoint is used by the grant type, the value of this parameter MUST be the same as the value of the "response_type" parameter passed to the authorization endpoint defined in the grant type definition. Authorization servers MAY allow for other values as defined in the grant type extension process is described in OAuth 2.0, Section 4.5. If omitted, the default is that the client will use only the "code" response type. STET API: only "code" can be used. type: array items: type: string enum: - code - token ClientName: description: | Human-readable string name of the client to be presented to the end-user during authorization. If omitted, the authorization server MAY display the raw "client_id" value to the end-user instead. It is RECOMMENDED that clients always send this field. The value of this field MAY be internationalized, as described in Section 2.2. type: string ClientUri: description: | URL string of a web page providing information about the client. If present, the server SHOULD display this URL to the end-user in a clickable fashion. It is RECOMMENDED that clients always send this field. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2. type: string LogoUri: description: | URL string that references a logo for the client. If present, the server SHOULD display this image to the end-user during approval. The value of this field MUST point to a valid image file. The value of this field MAY be internationalized, as described in Section 2.2. type: string Scope: description: | String containing a space-separated list of scope values (as described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client can use when requesting access tokens. The semantics of values in this list are service specific. If omitted, an authorization server MAY register a client with a default set of scopes. type: string Contacts: description: | Array of strings representing ways to contact people responsible for this client, typically email addresses. The authorization server MAY make these contact addresses available to end-users for support requests for the client. See Section 6 for information on Privacy Considerations. type: array items: type: string TosUri: description: | URL string that points to a human-readable terms of service document for the client that describes a contractual relationship between the end-user and the client that the end-user accepts when authorizing the client. The authorization server SHOULD display this URL to the end-user if it is provided. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2. type: string PolicyUri: description: | URL string that points to a human-readable privacy policy document that describes how the deployment organization collects, uses, retains, and discloses personal data. The authorization server SHOULD display this URL to the end-user if it is provided. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2. type: string JwksUri: description: | URL string referencing the client’s JSON Web Key (JWK) Set [RFC7517] document, which contains the client’s public keys. The value of this field MUST point to a valid JWK Set document. These keys can be used by higher-level protocols that use signing or encryption. For instance, these keys might be used by some applications for validating signed requests made to the token endpoint when using JWTs for client authentication [RFC7523]. Use of this parameter is preferred over the "jwks" parameter, as it allows for easier key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response. STET API: cannot be used. type: string x-not-used-by-stet: true ProviderLegalId: description: | Extension to RFC7591. Authorization number of the TPP according to ETSI specification on eIDAS certificates for PSD2. type: string ClientLegalId: description: | Extension to RFC7591. Authorization number of the agent. MUST BE present when the agent and the TPP are distinct entities. In a similar way to the ETSI specification on the Authorization Number for TPPs, the agent Authorization Number must respect the following format: - "AGT" as 3 character legal person identity type reference; - 2 character ISO 3166 country code representing the NCA country; - hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); and - 2-8 character NCA identifier (A-Z uppercase only, no separator); - hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); and - Agent identifier (registration number as specified by the NCA). type: string Logo: description: | Extension to RFC7591. Base64 encoded value of the client logo. type: string SoftwareId: description: | A unique identifier string (e.g., a Universally Unique Identifier (UUID)) assigned by the client developer or software publisher used by registration endpoints to identify the client software to be dynamically registered. Unlike "client_id", which is issued by the authorization server and SHOULD vary between instances, the "software_id" SHOULD remain the same for all instances of the client software. The "software_id" SHOULD remain the same across multiple updates or versions of the same piece of software. The value of this field is not intended to be human readable and is usually opaque to the client and authorization server. Not used in STET API type: string x-not-used-by-stet: true SoftwareVersion: description: | A version identifier string for the client software identified by "software_id". The value of the "software_version" SHOULD change on any update to the client software identified by the same "software_id". The value of this field is intended to be compared using string equality matching and no other comparison semantics are defined by this specification. The value of this field is outside the scope of this specification, but it is not intended to be human readable and is usually opaque to the client and authorization server. The definition of what constitutes an update to client software that would trigger a change to this value is specific to the software itself and is outside the scope of this specification. Not used in STET API type: string x-not-used-by-stet: true RegistrationRequest: description: structure of a client request type: object required: - redirect_uris - token_endpoint_auth_method - tls_client_auth_subject_dn - grant_types - client_name - contacts - provider_legal_id properties: redirect_uris: $ref: '#/definitions/RedirectUris' software_statement: description: | JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software as a bundle type: string token_endpoint_auth_method: $ref: '#/definitions/TokenEndpointAuthMethod' tls_client_auth_subject_dn: $ref: '#/definitions/TlsClientAuthSubjectDn' grant_types: $ref: '#/definitions/GrantTypes' response_types: $ref: '#/definitions/ResponseTypes' client_name: $ref: '#/definitions/ClientName' client_uri: $ref: '#/definitions/ClientUri' logo_uri: $ref: '#/definitions/LogoUri' scope: $ref: '#/definitions/Scope' contacts: $ref: '#/definitions/Contacts' tos_uri: $ref: '#/definitions/TosUri' policy_uri: $ref: '#/definitions/PolicyUri' jwks_uri: $ref: '#/definitions/JwksUri' provider_legal_id: $ref: '#/definitions/ProviderLegalId' client_legal_id: $ref: '#/definitions/ClientLegalId' logo: $ref: '#/definitions/Logo' jwks: $ref: '#/definitions/JsonWebKeySet' software_id: $ref: '#/definitions/SoftwareId' software_version: $ref: '#/definitions/SoftwareVersion' RegistrationRecord: description: | The response contains the client identifier as well as the client secret, if the client is a confidential client. type: object required: - client_id - registration_client_uri - registration_access_token properties: client_id: description: | REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion. type: string registration_client_uri: description: | REQUIRED. String containing the fully qualified URL of the client configuration endpoint for this client. type: string registration_access_token: description: | REQUIRED. String containing the access token to be used at the client configuration endpoint to perform subsequent operations upon the client registration. type: string client_secret: description: | OPTIONAL. OAuth 2.0 client secret string. If issued, this MUST be unique for each "client_id" and SHOULD be unique for multiple instances of a client using the same "client_id". This value is used by confidential clients to authenticate to the token endpoint, as described in OAuth 2.0 [RFC6749], Section 2.3.1. type: string client_id_issued_at: description: | OPTIONAL. Time at which the client identifier was issued. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of issuance. type: string format: date-time client_secret_expires_at: description: | REQUIRED if "client_secret" is issued. Time at which the client secret will expire or 0 if it will not expire. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of expiration. type: string format: date-time redirect_uris: $ref: '#/definitions/RedirectUris' token_endpoint_auth_method: $ref: '#/definitions/TokenEndpointAuthMethod' tls_client_auth_subject_dn: $ref: '#/definitions/TlsClientAuthSubjectDn' grant_types: $ref: '#/definitions/GrantTypes' response_types: $ref: '#/definitions/ResponseTypes' client_name: $ref: '#/definitions/ClientName' client_uri: $ref: '#/definitions/ClientUri' logo_uri: $ref: '#/definitions/LogoUri' scope: $ref: '#/definitions/Scope' contacts: $ref: '#/definitions/Contacts' tos_uri: $ref: '#/definitions/TosUri' policy_uri: $ref: '#/definitions/PolicyUri' jwks_uri: $ref: '#/definitions/JwksUri' provider_legal_id: $ref: '#/definitions/ProviderLegalId' client_legal_id: $ref: '#/definitions/ClientLegalId' logo: $ref: '#/definitions/Logo' jwks: $ref: '#/definitions/JsonWebKeySet' software_id: $ref: '#/definitions/SoftwareId' software_version: $ref: '#/definitions/SoftwareVersion' parameters: RegistrationRequestParameter: name: access in: body description: Registration data submitted by a given client. required: true schema: $ref: '#/definitions/RegistrationRequest' RegistrationRecordparameter: name: access in: body description: Registration data updated by a given client. required: true schema: $ref: '#/definitions/RegistrationRecord' ClientIdParameter: name: clientId in: path required: true description: | REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion. type: string ### Modified for CR383: Implement Http-Signature even when the signature certificate is not registered yet DigestHeader: name: Digest type: string in: header required: true description: Digest of the body ### Modified for CR383: Implement Http-Signature even when the signature certificate is not registered yet SignatureHeader: name: Signature type: string in: header required: true description: | http-signature of the request (cf. https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is - either an URL aiming to provide the relevant Qualified Certificate. - or the kid parameter retrieved through the certificate registration during a previous OAUTH2 Technical Setup Correlation: name: X-Request-ID type: string maxLength: 70 in: header required: true description: | Correlation header to be set in a request and retrieved in the relevant response