...
The client, policy and tos uris should be filled out
The client, policy and tos uris domain should match that at least one of the domains in the list of redirect uris (As suggested in https://openid.net/specs/openid-connect-registration-1_0.html#Impersonation). This should be validated at registration time.
The redirect uris scheme should be https and the host should not be localhost or loopback (127.0.0.1, ::1)The client should have generated a secret. Note that a client can still be registered with a localhost or loopback for testing, but verification would not be available.
A natural language description of the application must be included in the submission
...
The validation code is verified by the backend asynchronously, a worker will try and verify all the clients that are still pending. We might want to implement multiple retries before automatically rejecting a verification submission because of a failed domain validation (e.g. code mismatch).
If the sector_identifier_uri is provided during the client registration the list of redirect uris might potentially contain multiple domains. In order for a client to be validated all of the URIs needs to pass the domain validation.
Verification Status
A verification submission is associated with a status, one of: SUBMITTED, REJECTED, APPROVED. A verification approval is tied to the domain validation, the verification will include the information about the domain validation status. The verification cannot be approved if the domain is not validated.
If the verification is reject rejected the user should resubmit the verification with any changes indicated in the rejection reason.
...
We should allow to bypass the verification submission (e.g. for internal use or other mean of verification), in this case a submission from the user is not necessary and the client can be verified with a dedicated API call.
API Changes
There are some API changes needed in order to support this workflow, in particular a client is not usable if a secret was not generated and we therefore required the presence of a secret for verification. Our implementation deviates somehow from the specification, in the sense that the secret is not generated at registration time and is not returned in the GET /oauth2/client response. Instead we have a dedicated POST /oauth2/client/secret/{id} (shouldn't this be /oauth2/client/{id}/secret?) endpoint to (re)generate a secret.
For the web client to show the requirements for verification it needs to be able to gather the current status of the secret, we propose to include a boolean property secret_generated in the response of the GET /oauth/client/{id} which would also allow the web client to inform the user that a secret needs to be generated.Additionally we might want to add a new API call that returns the current secret for the user
GET /oauth2/client/secret/{id}
Proposed API
DT = Designated team for the verification review.
METHOD | URI | Notification | Request | Response | Description |
|---|---|---|---|---|---|
POST | /oauth2/client/{id}/verification | To the DT to review the verification request | OAuthClientVerification | OAuthClientVerification | Allows the user to submit a new verification for the client. Only the creator of the client can make this call. |
GET | /oauth2/client/{id}/verification | OAuthClientVerification | Gets the current verification for the client if any. Only the creator of the client can make this call. | ||
GET | /oauth2/client/{id}/verification/validationCode | OAuthClientValidationCode | Allows the user to retrieve the validation code used for domain validation. The code is generated once when the verification is submitted. | ||
POST | POST /oauth2/client/{id}/verification/status | To the verification creator | OAuthClientVerificationStatus | OAuthClientVerificationStatus | Allows the DT to approve/reject the verification. The possible state transitions are: SUBMITTED → APPROVED SUBMITTED → REJECTED |
POST | /oauth2/client/{id}/verified?status=<boolean> | Allows the DT to bypass the verification and set the client as verified or not independently from the verification. | |||
GET | /oauth2/client/verification | OAuthClientVerificationList | Allows the DT to retrieve a paginated list of verifications (sorted by creation date desc), optional parameters:
|
...
Field | Type | Description | |||
|---|---|---|---|---|---|
clientId | long | The id of the client this verification refers to | |||
clientDescription | string | Required description for the submission | |||
createdOn | date | The creation date | |||
createdBy | long | The id of the user that created the verification | |||
verificationStatus | OAuthClientVerificationStatus | The current verification status | |||
domainValidationStatus | OAuthClientDomainValidationStatus | The status of the domain validation | domainValidationCode | string | The code for the domain validation |
OAuthClientVerificationList
Field | Type | Description |
|---|---|---|
results | List<OAuthClientVerification> | The page of results |
nextPageToken | string | The token used to retrieve the next page if any. |
OAuthClientValidationCode
Field | Type | Description |
|---|---|---|
cliendId | long | The id of the client |
code | string | The code for the domain validation for any of the registred redirect uris |
References:
https://tools.ietf.org/html/rfc6749
...