+------------+                                       +--------------+
| Client App +-(A)---------------------------------->| Software API |
| Developer  | [Register]                            |   Publisher  |
|            |<--------------------------------------+              |
+-----+------+                                       +--------------+
      |
      v
+------------+                                                       
+ Builds App |                                                       
|Distribution| [Package & Distribute]                                
+-----+------+                                       +--------------+
     (B)   +---(C)-----------------------------------+ Pre-reg Auth |
      |    |                                         +--------------+
      v    V                                                         
+------------+                                       +--------------+
|            +-(D)----------------------------------->              |
|            | [POST/Register-Add]                   |              |
|            |<--------------------------------------+              |
|            |                  +-----------+        |    OAuth2    |
|            +-(E)------------->| OAuth2 AS |        |   SCIM JIT   |
| Client App | [Token Request]  |   Token   |        | Registration |
| Deployment |<-----------------+  Endpoint |        |   Endpoint   |
|  Instance  |                  +-----------+        |              |
|            +-(F)---------------------------------->|              |
|            | [PATCH/Update][PUT/Replace][GET/Read] |              |
|            |<--------------------------------------+              |
|            |                                       |              |
|            |                                       |              |
|            +-(G)---------------------------------->|              |
|            | [DELETE/Unregister]                   |              |
|            |<--------------------------------------+              |
+------------+                                       +--------------+

Figure 1: Figure 1: Registration Lifecycle Flow

The abstract OAuth 2.0 SCIM JIT Client Registration flow illustrated in Figure 1 describes the interaction between a software API publisher, a client developer, a deployed client software instance and the software API deployment registration services in this specification. This figure does not demonstrate error conditions. This flow includes the following steps:

(A)

Optionally, a client developer registers the clent application with a software API publisher. The software publisher, upon approval, generates a signed software assertion that is returned to the developer. While the software assertion is defined by this specification, the process of issuance is out-of-scope and is likely a web workflow the developer follows with the publisher.

(B)

The client developer packages the client software with the signed software assertion and distributes the client application. The method for doing this is out-of-scope of this specification.

(C)

Upon receiving a client application software distribution, a deploying organization may assign an initial access token, that can be used to authenticate a particular distribution of client software for use within the deploying organization's administrative domain. The mechanism for obtaining an initial access token and distributing it with a set of client software instances is out of scope of this application. One example might be a token supplied during the installation process of a client software, or it may inserted within a locally re-packaged distribution of the client application.

(D)

A client application performs an HTTP POST of a Client of a JSON structured resource to the registration endpoint. If the client received an iInitial access token in (C), it includes it in the HTTP Authorization field, otherwise, the registration is treated as an "anonymous" POST. An optional software assertion, received in (A), is included in the SCIM Client resource JSON being posted.

Upon successful registration, the SCIM Server returns a copy of the successful registration, including an assigned client_id and client credential (e.g. client_secret). In order for the client to access and update its registration in the future, an HTTP Location (client configuration endpoint) is returned specifying the location of the created SCIM resource.

(E)

As with any OAuth 2.0 protected resource, before a client may access and update its registration, the OAuth 2.0 client MUST obtain an access token. If the client received a "registration access token" in step (D), the client MAY use it. Alternatively, the client obtains an access token using the normal OAuth 2.0 a client credential flow section 4.3 [RFC6749] to obtain an access token with scope urn:oauth:scim:api:scope:registration.

(F)

The Client or Developer optionally calls the client configuration endpoint with a SCIM GET, PUT or PATCH request using the access token obtained in (E). Upon reading and or updating client registration data, a SCIM registration endpoint may choose to rotate the client credential.

(G)

The Client or Developer optionally calls the client configuration endpoint with a Delete request using the access token issued in (E).

Clients that need to register for more than one service API should typically make a separate registration request for each API being registered.

2. SCIM OAuth Client Resource Schema

This specification defines a new SCIM resource type known as a Client identified using the URI urn:scim:schemas:oauth:Client:1.0. [[Note include in IANA considerations]]

For each attribute defined, a qualifier (OPTIONAL, RECOMMENDED, REQUIRED) is included that indicates the usage requirement for the client. If the word "READ-ONLY" is used, it shall mean the attribute SHOULD be server generated. String attributes and mult-valued attributes are based on the attribute types defined in Section 3.1 and 3.2 [I-D.ietf-scim-core-schema]. Unless otherwise stated, ALL client schema attributes are String based values. For example, URIs, email addresses, identifiers, are all defined as SCIM String Attributes.

Extensions and profiles of this specification MAY expand this list. Authorization servers MUST accept all fields in this schema. The authorization server MUST ignore any additional parameters sent by the client that it does not understand. Clients MAY ignore additional parameters returned by the Server that the client does not understand.

2.1. Singular Attributes

The following is a list of attributes that MUST have only a SINGLE value.

client_id

OPTIONAL. An identifier whose value SHOULD be unique for EACH instance registered to a registration server. The value SHOULD be assigned by the registration endpoint on successful completion of the registration. While many clients may share a single software_id, each client instance SHOULD have a unique client_id. If a client registration expires or is revoked, the client MAY provide its previous registration value for continuity purposes (see Section 3.5).

software_assertion

OPTIONAL. A value containing a signed sofware assertion (see Section 4) from a software API publisher. Values in the assertion MAY be used as DEFAULT values for other client registration metadata.

software_id

RECOMMENDED. A unique identifier that identifies the software such as a UUID. The identifier SHOULD NOT change when software version changes or when a new installation instance is detected. software_id is intended to help a registration endpoint recognize a client's assertion that it is a prticular piece of software. Because of this, software identifier is usually associated with a particular client name. While client_idis linked to a client software deployment instance, the software_id is an identifier shared between all copies of the client software. Registration servers MAY use the supplied software identifier to determine whether a particular client software is approved or supported for use in the deployment domain.

software_version

RECOMMENDED. A version identifier such as a UUID or a number. Servers MAY use equality match to determine if a particular client is a particular version. software_version SHOULD change on any update to the client software. Registration servers MAY use the software version and identity to determine whether a particular client version is authorized for use in the deployment domain.

client_name

RECOMMENDED. A human-readable name of the client to be presented to the user. 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 Human Readable Client Metadata [HumanReadableClientMetadata].

client_secret

READ-ONLY. A value that is the OAuth 2.0 client_secret. This value SHOULD be assigned by the server. Any time the value is returned to the registered client, the server MAY rotate the value. Clients MUST check for any change in value returned and update their copy. The value is typically only used when the attribute token_endpoint_auth_method is set to client_post or client_basic.

client_uri

RECOMMENDED. A URL of the homepage of the client software. 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 Human Readable Client Metadata [HumanReadableClientMetadata].

jwks_uri

OPTIONAL. A URL for the client's JSON Web Key Set [JWK] document representing the client's public keys. The value of this field MUST point to a valid JWK Set. These keys MAY also be used for higher level protocols that require signing or encryption.

logo_uri

OPTIONAL. A URL that references a logo image 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 Human Readable Client Metadata [HumanReadableClientMetadata].

policy_uri

OPTIONAL. A 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 Human Readable Client Metadata [HumanReadableClientMetadata].

registration_token

READ-ONLY. An OAuth 2.0 Bearer Token [OAuth.JWT] known as the "registration access token". The token MAY be used by the client as a long-term access token used to update and manage the client's registration. The token is intended to allow the client to refresh its registration and obtain new client credentials in the event of expiry or revocation of the client credentials by the service API deployment domain. When client credentials are rotated, the registration access token SHOULD also be rotated.

scope

OPTIONAL. A space separated list of scope values (as described in Section 3.3 [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.

targetEndpoint

RECOMMENDED. A URI of the service API the client is registering for. The server MAY provide this value in its response. Clients requesting access to more than one target endpoint should register once for each target.

token_endpoint_auth_method

OPTIONAL. Value containing the requested authentication method for the Token Endpoint. The server MAY override the requested value. Clients MUST check for a change in value in the registration response. Values defined by this specification are:

• none: The client is a public client as defined in OAuth 2.0 and does not have a client secret.
• client_secret_post: The client uses the HTTP POST parameters defined in OAuth 2.0 section 2.3.1.
• client_secret_basic: the client uses HTTP Basic defined in OAuth 2.0 section 2.3.1

Additional values can be defined via the IANA OAuth Token Endpoint Authentication Methods registry

Section 6.1. Absolute URIs can also be used as values for this parameter. If unspecified or omitted, the default is client_secret_basic, denoting HTTP Basic Authentication Scheme as specified in Section 2.3.1 of OAuth 2.0.

tos_uri

OPTIONAL. A 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 Human Readable Client Metadata [HumanReadableClientMetadata].

2.2. Multi-valued Attributes

The following is a list of SCIM multi-valued attributes that MAY be part of a Client resource.

contacts

OPTIONAL. One or more email addresses for people responsible for this client. The authorization server MAY make these addresses available to end users for support requests for the client. An authorization server MAY use these email addresses as identifiers for an administrative page for this client.

redirect_uris

RECOMMENDED. One or more redirect URI values for use in redirect-based flows such as the Authorization Code and Implicit grant types. authorization servers SHOULD require registration of valid redirect URIs for all clients that use these grant types to protect against token and credential theft attacks.

grant_types

OPTIONAL. One or more OAuth 2.0 grant types that the client may use. These grant types are defined as follows:

• authorization_code: The Authorization Code Grant described in OAuth 2.0 Section 4.1
• implicit: The Implicit Grant described in OAuth 2.0 Section 4.2
• password: The Resource Owner Password Credentials Grant described in OAuth 2.0 Section 4.3
• client_credentials: The "Client credentials Grant" described in OAuth 2.0 Section 4.4
• refresh_token: The Refresh Token Grant described in OAuth 2.0 Section 6.
• urn:ietf:params:oauth:grant-type:jwt-bearer: The JWT Bearer grant type defined in OAuth JWT Bearer Token Profiles [OAuth.JWT].
• urn:ietf:params:oauth:grant-type:saml2-bearer: The SAML 2 Bearer grant type defined in OAuth SAML 2 Bearer Token Profiles [OAuth.SAML2].

Authorization servers MAY allow for other values as defined in grant type extensions to OAuth 2.0. The extension process is described in OAuth 2.0 Section 2.5, and 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 extension.

response_types

OPTIONAL. One or more OAuth 2.0 response types that the client may use. These response types are defined as follows:

• code: The Authorization Code response described in OAuth 2.0 Section 4.1.
• token: The Implicit response described in OAuth 2.0 Section 4.2.

Authorization servers MAY allow for other values as defined in response type extensions to OAuth 2.0. The extension process is described in OAuth 2.0 Section 2.5, and 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 extension.

2.3. Client Representation

{
  "schemas":["urn:scim:schemas:core:1.0",
             "urn:scim:schemas:oauth:2.0:Client"],
  "id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
  "resourceType":"Client",
  "software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
  "software_version":"5.1.2.3.4",
  "client_name":"Example Social Client",
  "logo_uri":"https://client.example.org/logo.png",
  "jwks_uri":"https://client.example.org/my_public_keys.jwks",
  "token_endpoint_auth_method":"client_secret_post",
  "scope":"read write dolphin",
  "client_id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
  "client_secret":"Z7tk2XqLKo1CfE14374teR4V554e8JUS",
  "redirect_urls":[""https://client.example.org/callback",
    "https://client.example.org/callback2"],
  "targetEndpoint":"https://social.example.com/base"
}

Figure 2: Example Client Resource

The following is a non-normative example of a fully populated SCIM OAuth 2.0 client registration in JSON format.

2.4. Relationship Between Grant Types and Response Types

The grant_types and response_types values described above are partially orthogonal, as they refer to arguments passed to different endpoints in the OAuth protocol. However, they are related in that the grant_types available to a client influence the response_types that the client is allowed to use, and vice versa. For instance, a grant_types value that includes authorization_code implies a response_types value that includes code, as both values are defined as part of the OAuth 2.0 Authorization Code Grant. As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.

The correlation between the two fields is listed in the table below.

Extensions and profiles of this document that introduce new values to either the grant_types or response_types parameter MUST document all correspondences between these two parameter types.

2.5. Human Readable Client Metadata

[[This needs to be updated to be compatible with SCIM. There is a also a problem with how to limit the amount of localization data exchange for an instance registration. Note that mobile clients tend to only need one preferred language while web clients represent many clients and may have more than 20 languages to support.]]

Human-readable Client Metadata values and client Metadata values that reference human-readable values MAY be represented in multiple languages and scripts. For example, the values of fields such as client_name, tos_uri, policy_uri, logo_uri, and client_uri might have multiple locale-specific values in some client registrations.

To specify the languages and scripts, BCP47 [RFC5646] language tags are added to client Metadata member names, delimited by a # character. Since JSON member names are case sensitive, it is RECOMMENDED that language tag values used in Claim Names be spelled using the character case with which they are registered in the IANA Language Subtag Registry [IANA.Language]. In particular, normally language names are spelled with lowercase characters, region names are spelled with uppercase characters, and languages are spelled with mixed case characters. However, since BCP47 language tag values are case insensitive, implementations SHOULD interpret the language tag values supplied in a case insensitive manner. Per the recommendations in BCP47, language tag values used in Metadata member names should only be as specific as necessary. For instance, using fr might be sufficient in many contexts, rather than fr-CA or fr-FR.

For example, a client could represent its name in English as "client_name#en": "My Client" and its name in Japanese as "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" within the same registration request. The authorization server MAY display any or all of these names to the Resource Owner during the authorization step, choosing which name to display based on system configuration, user preferences or other factors.

If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that clients and servers use a human-readable field without any language tags in addition to any language-specific fields, and it is RECOMMENDED that any human-readable fields sent without language tags contain values suitable for display on a wide variety of systems.

Implementer's Note: Many JSON libraries make it possible to reference members of a JSON object as members of an Object construct in the native programming environment of the library. However, while the # character is a valid character inside of a JSON object's member names, it is not a valid character for use in an object member name in many programming environments. Therefore, implementations will need to use alternative access forms for these claims. For instance, in JavaScript, if one parses the JSON as follows, var j = JSON.parse(json);, then the member client_name#en-us can be accessed using the JavaScript syntax j["client_name#en-us"].

2.6. Registration Server Processing Rules

A registration server MAY override any value that a client requests during the registration process (including any omitted values) and replace the requested value with a server generated value or default at the server's discretion.

If a software assertion is provided the registration server SHOULD validate the assertion as per Section 4.

3. SCIM Interaction Profile

All calls to the registration endpoint follow the HTTP verbs defined in [I-D.ietf-scim-api].

All resources accessible through the SCIM client registration endpoint are OAuth 2.0 protected. Clients that require access to their own registration resource, MAY use the registration access token (registration_token) returned after registration, OR obtain an access token from the token server endpoint using the client credentials flow Section 4.4 [RFC6749], and scope urn:oauth:scim:api:scope:registration.

The initial access token used in the initial registration SHOULD NOT be used for this purpose of managing or updating client resources. Access to the client registration base for the purpose of adding a new registration MAY permit anonymous access as desribed in the next section.

Clients SHOULD NOT be able to access the registration resources of other clients.

Clients with expired client credentials SHOULD follow the procedures in Section 3.5.

3.1. Adding A Registration

Adding a registration follows the normal SCIM method for creating a resource (an HTTP POST) as described in Section 3.1 [I-D.ietf-scim-api].

3.1.1. Anonymous Registration

The SCIM registration endpoint MAY support anonymous registration for those clients that have not been issued an initial access token. For those clients that have been issued a software assertion, the clients SHOULD include this assertion in the software_assertion field of the client resource being created. The Server SHOULD validate the assertion and validate the issuer, subject, audience, and expiry fields as described in Section 4.1.

For a non-normative example, see Figure 2. In the anonymous case, the HTTP Authorization header is omitted.

3.1.2. Pre-Authorized Registration

POST /Users  HTTP/1.1
Host: example.com
Accept: application/json
Content-Type: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas":["urn:scim:schemas:core:1.0",
             "urn:scim:schemas:oauth:2.0:Client"],
  "software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
  "software_assertion":"eyJhbGciOiJSUzI1NiJ9.",
  "software_version":"5.1.2.3.4",
  "client_name":"Example Social Client",
  "logo_uri":"https://client.example.org/logo.png",
  "jwks_uri":"https://client.example.org/my_public_keys.jwks",
  "token_endpoint_auth_method":"client_secret_post",
  "scope":"read write dolphin",
  "redirect_urls":[""https://client.example.org/callback",
    "https://client.example.org/callback2"],
  "targetEndpoint":"https://social.example.com/base"
}

HTTP/1.1 201 Created
Content-Type: application/json
Location: 
  https://example.com/v2/Clients/2060107e82-42bd-b199-15df7081a8ae
ETag: W/"e180ee84f0671b1"

{
  "schemas":["urn:scim:schemas:core:1.0",
             "urn:scim:schemas:oauth:2.0:Client"],
  "resourceType":"Client",
  "id":"2060107e82-42bd-b199-15df7081a8ae",
  "software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
  "software_assertion":"eyJhbGciOiJSUzI1NiJ9.",
  "software_version":"5.1.2.3.4",
  "client_name":"Example Social Client",
  "logo_uri":"https://client.example.org/logo.png",
  "jwks_uri":"https://client.example.org/my_public_keys.jwks",
  "token_endpoint_auth_method":"client_secret_post",
  "scope":"read write dolphin",
  "client_id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
  "client_secret":"Z7tk2XqLKo1CfE14374teR4V554e8JUS",
  "redirect_urls":[""https://client.example.org/callback",
    "https://client.example.org/callback2"],
  "targetEndpoint":"https://social.example.com/base"
}

GET /Clients/?
  filter=client_id%20eq%2060107e82-fbe3-42bd-b199-15df7081a8ae

Host: example.com
Accept: application/json
Authorization: Bearer deadbeef

HTTP/1.1 200 OK
Content-Type: application/json

{
  "totalResults":1,
  "schemas":["urn:scim:schemas:core:1.0",
             "urn:scim:schemas:oauth:Client:1.0"],
  "Resources":[
     {
      "id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
      "resourceType":"Client",
      "software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
      "software_version":"5.1.2.3.4",
      "client_name":"Example Social Client",
...
      "token_endpoint_auth_method":"client_secret_post",
      "client_id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
      "client_secret":"Z7tk2XqLKo1CfE14374teR4V554e8JUS"
     }
  ]
}

[
 ...
  {
    "name": "Client",
    "endpoint": "/Clients",
    "schema": "urn:scim:schemas:oauth:2.0"
  },
 ...
]

{  "id":"urn:scim:schemas:oauth:2.0:Client",
  "name":"Client",
  "description":"OAuth 2 Client",
  "schema":["urn:scim:core:1.0",
            "urn:scim:schemas:oauth:2.0"],
  "endpoint":"/Clients",
  "attributes":[
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "description":"Unique identifier for the SCIM resource....",
      "readOnly":true,
      "required":true,
      "caseExact":false
    },
    {
      "name":"client_id",
      "type":"string",
      "multiValued":false,
      "description":
        "OAuth 2.0 client_id assigned to the registered client.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"software_assertion",
      "type":"string",
      "multiValued":false,
      "description":
        "A signed JWT assertion about the client.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"software_id",
      "type":"string",
      "multiValued":false,
      "description":"Unique identifier for client software.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"software_version",
      "type":"string",
      "multiValued":false,
      "description":"A version identifier for the software.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"client_name",
      "type":"string",
      "multiValued":false,
      "description":"A human readable name of the client.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"client_secret",
      "type":"string",
      "multiValued":false,
      "description":
        "A client secret assigned by the registration endpoint.",
      "readOnly":true,
      "required":false,
      "caseExact":true
    },
    {
      "name":"client_uri",
      "type":"string",
      "multiValued":false,
      "description":
        "URL of homepage for client(displayable to an end-user).",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"jwks_uri",
      "type":"string",
      "multiValued":false,
      "description":"A URL for the client's JSON Web Key Set.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"logo_uri",
      "type":"string",
      "multiValued":false,
      "description":"A URL that references a logo image for client.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"policy_uri",
      "type":"string",
      "multiValued":false,
      "description":
        "A URL of a human-readable policy document for the client.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"registration_token",
      "type":"string",
      "multiValued":false,
      "description":
        "A token issued to client for updating its registration.",
      "readOnly":true,
      "required":false,
      "caseExact":true
    },
    {
      "name":"scope",
      "type":"string",
      "multiValued":false,
      "description":"Registered OAuth 2 scopes the client uses.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"targetEndpoint",
      "type":"string",
      "multiValued":false,
      "description":
        "The OAuth2 resource endpoint the client intends to access.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"token_endpoint_auth_method",
      "type":"string",
      "multiValued":false,
      "description":"OAuth 2 Token Endpoint authorization method.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"tos_uri",
      "type":"string",
      "multiValued":false,
      "description":
        "A URL pointing to a human readable terms of service.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"contacts",
      "type":"string",
      "multiValued":true,
      "description":
        "One or more email addresses of contacts for client.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"redirect_uris",
      "type":"string",
      "multiValued":true,
      "description":"One or more OAuth 2 redirect URI values.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"grant_types",
      "type":"string",
      "multiValued":true,
      "description":
        "One or more OAuth 2 grant types the client may use.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
    {
      "name":"response_types",
      "type":"string",
      "multiValued":true,
      "description":"One or more OAuth 2 response types.",
      "readOnly":false,
      "required":false,
      "caseExact":true
    },
  ]
}