{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "id": "http://localhost:3000/schemas/post-client-request.json#",
    "title": "client",
    "type": "object",
    "additionalProperties": false,
    "required": [
        "redirect_uris"
    ],
    "properties": {
        "redirect_uris": {
            "type": "array",
            "items": {
                "type": "string"
            },
            "description": "Array of redirect URIs for use in redirect-based flows such as the authorization code and implicit grant types.  It is RECOMMENDED that clients using these flows register this parameter, and an authorization server SHOULD require registration of valid redirect URIs for all clients that use these grant types to protect against token and credential theft attacks."
        },
        "responses_types": {
            "type": "array",
            "enum": [
                "code",
                "token"
            ],
            "description": "Array of the OAuth 2.0 response types that the client may use"
        },
        "grant_types": {
            "type": "array",
            "description": "Array of OAuth 2.0 grant types that the client may use",
            "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"
                ]
            }
        },
        "application_type": {
            "type": "string",
            "default": "web",
            "enum": [
                "web",
                "native"
            ],
            "description": "OPTIONAL. Kind of the application. The default, if omitted, is web. The defined values are native or web. Web Clients using the OAuth Implicit Grant Type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers MAY place additional constraints on Native Clients. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the localhost case for Native Clients. The Authorization Server MUST verify that all the registered redirect_uris conform to these constraints. This prevents sharing a Client ID across different types of Clients."
        },
        "contacts": {
            "type": "array",
            "items": {
                "type": "string"
            },
            "description": "Array of e-mail addresses of people responsible for this Client. This might be used by some providers to enable a Web user interface to modify the Client information."
        },
        "client_name": {
            "type": "string",
            "description": "Human-readable name of the client to be presented to the user during authorization.  If omitted, the authorization server MAY display the raw \"client_id\" value to the 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."
        },
        "logo_uri": {
            "type": "string",
            "description": "URL 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."
        },
        "client_uri": {
            "type": "string",
            "description": "URL 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."
        },
        "tos_uri": {
            "type": "string",
            "description": "URL that points to a human-readable Terms of Service document for the client. The Authorization Server SHOULD display this URL to the end-user if it is given. The Terms of Service usually describe a contractual relationship between the end-user and the client that the end-user accepts when authorizing the client.  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."
        },
        "policy_uri": {
            "type": "string",
            "description": "URL that points to a human-readable Policy document for the client. The authorization server SHOULD display this URL to the end-user if it is given.  The policy usually describes how an end-user's data will be used by the client.  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."
        },
        "jwks_uri": {
            "type": "string",
            "description": "URL of the client's JSON Web Key Set [JWK] document containing 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."
        },
        "jwks": {
            "type": "string",
            "description": "JSON Web Key Set [JWK] value containing the client's public keys. The value of this field MUST be a JSON object containing a valid JWK Set. These keys can be used by higher level protocols that use signing or encryption.  This parameter is intended to be used by clients that cannot use the \"jwks_uri\" parameter.  For instance, a native application might not have a location to host the contents of the JWK Set that would be reachable by the authorization server.  The \"jwks_uri\" and \"jwks\" parameters MUST NOT be used together."
        },
        "sector_identifier_uri": {
            "type": "string",
            "description": "URL using the https scheme to be used in calculating Pseudonymous Identifiers by the OP. The URL references a file with a single JSON array of redirect_uri values. Please see Section 5. Providers that use pairwise sub (subject) values SHOULD utilize the sector_identifier_uri value provided in the Subject Identifier calculation for pairwise identifiers."
        },
        "subject_type": {
            "type": "string",
            "enum": [
                "pairwise",
                "public"
            ],
            "description": "subject_type requested for responses to this Client. The subject_types_supported Discovery parameter contains a list of the supported subject_type values for this server. Valid types include pairwise and public."
        },
        "id_token_signed_response_alg": {
            "type": "string",
            "description": "JWS alg algorithm [JWA] REQUIRED for signing the ID Token issued to this Client. The value none MUST NOT be used as the ID Token alg value unless the Client uses only Response Types that return no ID Token from the Authorization Endpoint (such as when only using the Authorization Code Flow). The default, if omitted, is RS256. The public key for validating the signature is provided by retrieving the JWK Set referenced by the jwks_uri element from OpenID Connect Discovery 1.0 [OpenID.Discovery]."
        },
        "id_token_encrypted_response_alg": {
            "type": "string",
            "description": "JWE alg algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If this is requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that no encryption is performed."
        },
        "id_token_encrypted_response_enc": {
            "type": "string",
            "description": "JWE enc algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If id_token_encrypted_response_alg is specified, the default for this value is A128CBC-HS256. When id_token_encrypted_response_enc is included, id_token_encrypted_response_alg MUST also be provided."
        },
        "userinfo_signed_response_alg": {
            "type": "string",
            "description": "JWS alg algorithm [JWA] REQUIRED for signing UserInfo Responses. If this is specified, the response will be JWT [JWT] serialized, and signed using JWS. The default, if omitted, is for the UserInfo Response to return the Claims as a UTF-8 encoded JSON object using the application/json content-type."
        },
        "userinfo_encrypted_response_alg": {
            "type": "string",
            "description": "JWE [JWE] alg algorithm [JWA] REQUIRED for encrypting UserInfo Responses. If both signing and encryption are requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that no encryption is performed."
        },
        "userinfo_encrypted_response_enc": {
            "type": "string",
            "description": "JWE enc algorithm [JWA] REQUIRED for encrypting UserInfo Responses. If userinfo_encrypted_response_alg is specified, the default for this value is A128CBC-HS256. When userinfo_encrypted_response_enc is included, userinfo_encrypted_response_alg MUST also be provided."
        },
        "request_object_signing_alg": {
            "type": "string",
            "description": "JWSJones, M., Bradley, J., and N. Sakimura, \u201cJSON Web Signature (JWS),\u201d July 2014. [JWS] alg algorithm [JWA] that MUST be used for signing Request Objects sent to the OP. All Request Objects from this Client MUST be rejected, if not signed with this algorithm. Request Objects are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. This algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support RS256. The value none MAY be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used."
        },
        "request_object_encryption_alg": {
            "type": "string",
            "description": "JWEJones, M., Rescorla, E., and J. Hildebrand, \u201cJSON Web Encryption (JWE),\u201d July 2014. [JWE] alg algorithm [JWA] the RP is declaring that it may use for encrypting Request Objects sent to the OP. This parameter SHOULD be included when symmetric encryption will be used, since this signals to the OP that a client_secret value needs to be returned from which the symmetric key will be derived, that might not otherwise be returned. The RP MAY still use other supported encryption algorithms or send unencrypted Request Objects, even when this parameter is present. If both signing and encryption are requested, the Request Object will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that the RP is not declaring whether it might encrypt any Request Objects."
        },
        "request_object_encryption_enc": {
            "type": "string",
            "description": "JWE enc algorithm [JWA] the RP is declaring that it may use for encrypting Request Objects sent to the OP. If request_object_encryption_alg is specified, the default for this value is A128CBC-HS256. When request_object_encryption_enc is included, request_object_encryption_alg MUST also be provided."
        },
        "token_endpoint_auth_method": {
            "type": "string",
            "description": "Requested Client Authentication method for the Token Endpoint. The options are client_secret_post, client_secret_basic, client_secret_jwt, private_key_jwt, and none, as described in Section 9 of OpenID Connect Core 1.0 [OpenID.Core]. Other authentication methods MAY be defined by extensions. If omitted, the default is client_secret_basic -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].",
            "description_none": "The client is a public client as defined in OAuth 2.0 and does not have a client secret.",
            "description_client_secret_post": "The client uses the HTTP POST parameters defined in OAuth 2.0",
            "description_client_secret_basic": "the client uses HTTP Basic defined in OAuth 2.0",
            "enum": [
                "client_secret_post",
                "client_secret_basic",
                "client_secret_jwt",
                "private_key_jwt",
                "none"
            ],
            "default": "client_secret_basic"
        },
        "token_endpoint_auth_signing_alg": {
            "type": "string",
            "description": "JWSJones, M., Bradley, J., and N. Sakimura, \u201cJSON Web Signature (JWS),\u201d July 2014. [JWS] alg algorithm [JWA] that MUST be used for signing the JWT [JWT] used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. All Token Requests using these authentication methods from this Client MUST be rejected, if the JWT is not signed with this algorithm. Servers SHOULD support RS256. The value none MUST NOT be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used."
        },
        "default_max_age": {
            "type": "string",
            "description": "Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified."
        },
        "require_auth_time": {
            "type": "string",
            "description": " Boolean value specifying whether the auth_time Claim in the ID Token is REQUIRED. It is REQUIRED when the value is true. (If this is false, the auth_time Claim can still be dynamically requested as an individual Claim for the ID Token using the claims request parameter described in Section 5.5.1 of OpenID Connect Core 1.0 [OpenID.Core].) If omitted, the default value is false."
        },
        "default_acr_values": {
            "type": "array",
            "description": "Default requested Authentication Context Class Reference values. Array of strings that specifies the default acr values that the OP is being requested to use for processing requests from this Client, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value in the issued ID Token. The acr Claim is requested as a Voluntary Claim by this parameter. The acr_values_supported discovery element contains a list of the supported acr values supported by this server. Values specified in the acr_values request parameter or an individual acr Claim request override these default values."
        },
        "initiate_login_uri": {
            "type": "string",
            "description": "URI using the https scheme that a third party can use to initiate a login by the RP, as specified in Section 4 of OpenID Connect Core 1.0 [OpenID.Core]. The URI MUST accept requests via both GET and POST. The Client MUST understand the login_hint and iss parameters and SHOULD support the target_link_uri parameter."
        },
        "request_uris": {
            "type": "string",
            "description": "Array of request_uri values that are pre-registered by the RP for use at the OP. Servers MAY cache the contents of the files referenced by these URIs and not retrieve them at the time they are used in a request. OPs can require that request_uri values used be pre-registered with the require_request_uri_registration discovery parameter. If the contents of the request file could ever change, these URI values SHOULD include the base64url encoded SHA-256 hash value of the file contents referenced by the URI as the value of the URI fragment. If the fragment value used for a URI changes, that signals the server that its cached value for that URI with the old fragment value is no longer valid."
        },
        "scope": {
            "type": "array",
            "items": {
                "type": "string"
            },
            "description": "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 is service specific.  If omitted, an authorization server MAY register a client with a default set of scopes."
        },
        "software_id": {
            "type": "string",
            "description": "Identifier for the software that comprises a client. Unlike \"client_id\", which is issued by the authorization server and may vary between instances, the \"software_id\" is asserted by the client software and is intended to be shared among all instances of the client software. The identifier SHOULD NOT change when software version changes or when a new installation occurs."
        },
        "software_version": {
            "type": "string",
            "description": "Version identifier for the software that comprises a client. The value of this field is a string that is intended to be compared using string equality matching.  The value of the \"software_version\" SHOULD change on any update to the client software."
        }
    }
}