{
    "client_id (string)": "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.\n",
    "registration_client_uri (string)": "REQUIRED. String containing the fully qualified URL of the client configuration endpoint for this client.\n",
    "registration_access_token (string)": "REQUIRED. String containing the access token to be used at the client configuration endpoint to perform subsequent operations upon the client registration.\n",
    "client_secret (string)": "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.\n",
    "client_id_issued_at (string)": "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.\n",
    "client_secret_expires_at (string)": "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.\n",
    "redirect_uris (array)": "Array of redirection URIs for use in redirect-based flows",
    "token_endpoint_auth_method (string)": "Requested authentication method for the token endpoint.\n* \"none\": The client is a public client as defined in OAuth 2.0, Section 2.1, and does not have a client secret.\n* \"client_secret_post\": The client uses the HTTP POST parameters as defined in OAuth 2.0, Section 2.3.1.\n* \"client_secret_basic\": The client uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1.\n* \"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.\nSTET API: only \"tls_client_auth\" can be used in order to comply with MTLS method used for PSD2 API.\n",
    "grant_types (array)": "Array of OAuth 2.0 grant type strings that the client can use at the token endpoint. These grant types are defined as follows:\n* \"authorization_code\": The authorization code grant type defined in OAuth 2.0, Section 4.1.\n* \"implicit\": The implicit grant type defined in OAuth 2.0, Section 4.2.\n* \"password\": The resource owner password credentials grant type defined in OAuth 2.0, Section 4.3.\n* \"client_credentials\": The client credentials grant type defined in OAuth 2.0, Section 4.4.\n* \"refresh_token\": The refresh token grant type defined in OAuth  2.0, Section 6.\n* \"urn:ietf:params:oauth:grant-type:jwt-bearer\": The JWT Bearer Token Grant Type defined in OAuth JWT Bearer Token Profiles [RFC7523].\n* \"urn:ietf:params:oauth:grant-type:saml2-bearer\": The SAML 2.0 Bearer Assertion Grant defined in OAuth SAML 2 Bearer Token Profiles [RFC7522].\n\nIf 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.\nSTET API: allowed values are:\n* authorization_code\n* password\n* client_credentials\n* refresh_token          \n",
    "response_types (array)": "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:\n* \"code\": The authorization code response type defined in OAuth 2.0, Section 4.1.\n* \"token\": The implicit response type defined in OAuth 2.0, Section 4.2.\nIf 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.\nSTET API: only \"code\" can be used.\n",
    "client_name (string)": "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.\n",
    "client_uri (string)": "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.\n",
    "logo_uri (string)": "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.\n",
    "scope (string)": "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.\n",
    "contact": {
        "contact_name (string)": "Human-readable string name of the contact to be presented to the end-user during authorization. The value of this field MAY be internationalized, as described in Section 2.2.\n"
    },
    "tos_uri (string)": "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.\n",
    "policy_uri (string)": "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.\n",
    "jwks_uri (string)": "URL string referencing the client\u2019s JSON Web Key (JWK) Set [RFC7517] document, which contains the client\u2019s 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.\nSTET API: cannot be used.\n",
    "provider_legal_id (string)": "Extension  to RFC7591.\nAuthorization number of the TPP according to ETSI specification on eIDAS certificates for PSD2.\n",
    "client_legal_id (string)": "Extension to RFC7591.\nAuthorization number of the agent. MUST BE present when the agent and the TPP are distinct entities.\nIn a similar way to the ETSI specification on the Authorization Number for TPPs, the agent Authorization Number must respect the following format:\n- \"AGT\" as 3 character legal person identity type reference;\n- 2 character ISO 3166 country code representing the NCA country;\n- hyphen-minus \"-\" (0x2D (ASCII), U+002D (UTF-8)); and\n- 2-8 character NCA identifier (A-Z uppercase only, no separator);\n- hyphen-minus \"-\" (0x2D (ASCII), U+002D (UTF-8)); and \n- Agent identifier (registration number as specified by the NCA).          \n",
    "logo (string)": "Extension to RFC7591.\nBase64 encoded value of the client logo.\n",
    "jwks": {
        "keys (array)": "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.\n"
    },
    "software_id (string)": "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.\nNot used in STET API\n",
    "software_version (string)": "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.\nNot used in STET API\n"
}