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
      
  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
      * password
      * client_credentials
      * refresh_token          
    type: array
    items:
      type: string
      enum:
        - authorization_code
        - implicit
        - password
        - 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
    
  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        
  
  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        
  

  RegistrationRequest:
    description: structure of a client request
    type: object
    required:
      - redirect_uris
      - token_endpoint_auth_method
      - 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'      
      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'      
      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
  