OpenID Connect User Questioning API 1.0 Orange
nicolas.aillery@orange.com
Orange
charles.marais@orange.com
OpenID MODRNA Working Group This specification defines a specific endpoint used by a Client (i.e. Service Provider) in order to question a End-User and get his Statement (i.e. his answer).
This specification defines a specific endpoint used by a Client (i.e. Service Provider) in order to question a End-User and get his Statement (i.e. his answer). This endpoint is specified as an OAuth 2.0-protected Resource Server accessible with an Access Token. The way the Access Token has been obtained by the Client is out of scope of this specification. Whether the End-User is currently using the Client or not is also out of scope of this specification. The User Questioning API is an asynchronous API. There are 3 main ways to get the End-User's Statement: the first one requires some polling of the API, the second requires the Client to expose a callback endpoint and the third one requires a user interaction on the Client.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
This specification uses the terms "Access Token", "Resource Server", and "Client" defined by OAuth 2.0. This specification also defines the following terms: End-User receiving the question and requested to give his Statement.
The User Questioning protocol, in abstract, follows the following steps. The Client sends a User Questioning Request to the OpenID Provider (OP). The OP interacts with the Questioned User and obtains his Statement. The OP responds to the Client with a User Questioning Response. These steps are illustrated in the following diagram:
+--------+ +--------+ | | | | | |----(1) User Questioning Request-------------->| | | | | | | | +--------+ | | | | | | | | | Client | | End- |<--(2) User interactions to get--->| OP | | | | User | the Questioned User's Statement | | | | | | | | | | +--------+ | | | | | | | |<----(3) User Questioning Response-------------| | | | | | +--------+ +--------+
The following use cases are non-normative examples to illustrate the usage of the User Questioning API by a Client. The Client can be a bank and the User Questioning API is used to challenge the End-User when he wants to pay on Internet in order to secure the transaction. This is similar to 3D-Secure. The question could be: "Do you allow a payment of x euros to party y?". The Client can be a bank and the User Questioning API is used to challenge the End-User when he wants to add a new payee for a bank transfer. The question could be: "Do you allow party y to be added to your payees?". The Client can be a drive-in food market and the User Questioning API is used to ask the End-User if he accepts the exchange of one missing product by another. The question could be: "Do you agree to get product x instead of product y?". The Client can be a ticketing platform and the User Questioning API is used to prevent transactions by bots. The question could be: "Do you confirm that you are currently booking a ticket?". The Client can be an airline company and the User Questioning API is used to be sure that the End-User is notified of a delay. The question could be: "Your flight is postponed. Can you confirm that you are aware?".
Here after is described the User Statement Token : Attribute Type Description Example status string Status code of the Question. Possible values are described in . "pending" statement string Statement made by the Questioned User. Possible values are described in . "accepted" creation_date timestamp Date indicating when the User Questioning Request has been received by the OP. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. 1311281970 last_modification_date timestamp Date indicating the last change of the status. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. 1311281970 statement_date timestamp Date indicating when the End-User gave his Statement on the Question. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. 1311282970 user_id string Unique identifier allowing to identify the Questioned User (e.g. Mobile phone , sub, ...). Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. 3444975f-1137-47dc-908f-942ac85ab98f user_id_type string Indicate the type of the End-User's identifier used for User Questioning. Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. Possible values are described in . MSISDN question_displayed string Question that was displayed to the Questioned User. An example message to display used_qcr string Questioning context class reference : Level of Assurance used by the OP (can be 2 3 4). 2 used_qmr string Questioning method used by the OP for the User Questioning. SMS_OTP
user_id_type member can take the following values : Value Description Example MSISDN Represents the Mobile Phone number corresponding to the Questioned User. The way this MSISDN has been captured by the Client is out of scope of this specification. 33612345678 sub Represents the sub corresponding to the Questioned User. The way this sub has been captured by the Client is out of scope of this specification. 8d858e0a-c91b-426a-92e8-462d3876df7d
status member can take the following values : Value Description pending This status name is returned when the User Questioning is ongoing. terminated This status name is returned when the User Questioning is finished.
By default, statement member can take the following values : Value Description accepted This statement is returned when the Questioned User's Statement is an acceptation. denied This statement is returned when the Questioned User's Statement is a deny. The statement can take other values in order to address specific use cases. For example, the question could ask for a number or a choice amongst several possibilities. These specific statement values SHOULD be specified in extensions of this specification or in an ad-hoc agreement between the Clients and the OP.
This document specifies three User Questioning flows: In this flow, after the User Questioning Request, the Client must call the OP in order to get the User Questioning Response. Refer to for more details. In this flow, after the User Questioning Request, the OP calls the Client to deliver the User Questioning Response. Refer to for more details. In this flow, after the User Questioning Request, the Client must call the OP with an additional verification_code in order to get the User Questioning Response. Refer to for more details. The flow to use is decided by the OP and depends on the User Questioning Request and the available User Questioning mechanisms: If the Client does not include a client_notification_endpoint in the User Questioning Request and if the User Questioning mechanism selected by the OP does not require additional information from the Client (e.g. verification_code). Refer to for more details. If the Client includes a client_notification_endpoint in the User Questioning Request and if the User Questioning mechanism selected by the OP does not require additional information from the Client (e.g. verification_code). Refer to for more details. If the User Questioning mechanism selected by the OP requires additional information from the Client (e.g. verification_code). Refer to for more details.
In this flow, the Client MUST NOT include a client_notification_endpoint in the User Questioning Request. The Client will poll the OP until the User Questioning is finished (accepted, denied, error...). If a verification_code is needed for the mecanism chosen by the OP, the flow will be the Terminated-By-Client Flow (cf. ).
+--------+ +--------+ | |---(1a) User Questioning Request-------------->| | | | | | | |<--(1b) Question Created-----------------------| | | | | | | | +--------+ | | | Client | | End- |<--(2a) User interactions to get-->| OP | | | | User | the Questioned User's Statement | | | | +--------+ | | | | | | | |--(3a) Get User Questioning Response---------->| | | | | | | |<---(3b) User Questioning Response-------------| | +--------+ +--------+
The Client sends the User Questioning Request using HTTP GET or HTTP POST. The Access Token obtained from an OAuth Authorization request MUST be sent as a Bearer Token. The User Questioning Request MUST contain the following attributes, either in the query string for the HTTP GET method or form serialized in the body for the HTTP POST method. Attribute name Presence Type Description Example user_id FORBIDDEN if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User string Unique identifier allowing to identify the Questioned User (e.g. Mobile phone , sub, ...). Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. 3444975f-1137-47dc-908f-942ac85ab98f user_id_type FORBIDDEN if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User string Indicate the type of the End-User's identifier used for User Questioning. Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. Possible values are described in . MSISDN question_to_display MANDATORY string Question to be displayed to the Questioned User. An example message to display wished_qcr MANDATORY string Questioning context class reference : Level of Assurance wished by the Client (can be 2 3 4). 3 wished_qmr OPTIONAL string Questioning method wished by the Client SMS_OTP In this flow, the Client MUST NOT include a client_notification_endpoint in the User Questioning Request.
This example describes a context where the access_token is tied with a specific End-User. If the Client add user_id / user_id_type in the request, these parameters will be ignored. The following is a non-normative example using HTTP GET.
GET /questions? question_to_display=An%20example%20message%20to%20display &wished_qcr=3 Host: server.example.com Accept: application/json Authorization: Bearer SlAV32hkKG
This example describes a context where the access_token is tied with a specific End-User. If the Client add user_id / user_id_type in the request, these parameters will be ignored. The following is a non-normative example using HTTP POST.
POST /questions HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Accept: application/json Authorization: Bearer SlAV32hkKG question_to_display=An%20example%20message%20to%20display&wished_qcr=3
This example describes a context where the access_token is not tied with a specific End-User. The Client MUST add user_id and user_id_type in the request. The following is a non-normative example using HTTP GET.
GET /questions? user_id=33612345678 &user_id_type=MSISDN &question_to_display=An%20example%20message%20to%20display &wished_qcr=3 Host: server.example.com Accept: application/json Authorization: Bearer SlAV32hkKG
The following is a non-normative example using HTTP POST.
POST /questions HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Accept: application/json Authorization: Bearer SlAV32hkKG user_id=33612345678&user_id_type=MSISDN &question_to_display=An%20example%20message%20to%20display&wished_qcr=3
The Client receives a HTTP 201 Created response. The response body contains a JSON object with the following attributes. Parameter name Presence Type Description Example id MANDATORY string Unique identifier of the Question. 984dcc7d-3d4d-4b0f-9f80-22e344f9a956 status MANDATORY string Status code of the Question (note that Error codes are handled by the HTTP protocol). "pending" In this flow, there are two possible status in the received JSON object: This is the temporary status when the User Questioning Response is not ready. This is a temporary status when an additional verification_code is required. If the status is verification_code_required, then the current flow is the Terminated-By-Client Flow ().
The following is a non-normative example.
HTTP/1.1 201 Created Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"pending", }
The Client receives a HTTP 400 Bad Request as specified in .
The way the User Questioning Endpoint obtains the Questioned User's Statement for the Question is out of the scope of this specification.
The Client get the User Questioning Response using HTTP GET. The Access Token obtained from an OAuth Authorization request MUST be sent as a Bearer Token. In order to detect that User Questioning Response is ready, the Client MUST request the User Questioning Response. If User Questioning Response is ready, it will be returned in the response. Else, the OP responds with HTTP 304 Not Modified.
The following is a non-normative example.
GET /questions/84c1d9d6-62e5-4803-ac0e-36b858c HTTP/1.1 Host: server.example.com Accept: application/json Authorization: Bearer SlAV32hkKG
The Client receives the User Questioning Response in a HTTP 200 OK or HTTP 304 Not Modified response.
If the User Questioning Response is not ready, the Client will get a HTTP 304 Not Modified.
The following is a non-normative example.
HTTP/1.1 304 Not Modified
The Client receives the User Questioning Response in a HTTP 200 OK response. The User Questioning Response contains a User Statement Token in the response body .
The following is a non-normative example.
HTTP/1.1 200 OK Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"accepted", "creation_date":"1311281970", "last_modification_date":"1311282970", "statement_date":"1311282970", "question_displayed":"An example message to display", "used_qcr":"2", "used_qmr":"SMS_OTP" }
The following is a non-normative example.
HTTP/1.1 200 OK Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"denied", "creation_date":"1311281970", "last_modification_date":"1311282970", "statement_date":"1311282970", "question_displayed":"An example message to display", "used_qcr":"2", "used_qmr":"SMS_OTP" }
The Client receives a HTTP 400 Bad Request as specified in .
In this flow, the Client MUST include a client_notification_endpoint in the User Questioning Request. The Client will be informed at this endpoint by the OP when the User Questioning is finished (accepted, denied, error...). If a verification_code is needed for the mecanism chosen by the OP, the flow will be the Terminated-By-Client Flow (cf. ), despite the client_notification_endpoint in the request.
+--------+ +--------+ | |---(1a) User Questioning Request-------------->| | | | | | | |<--(1b) Question Created-----------------------| | | | | | | | +--------+ | | | Client | | End- |<--(2a) User interactions to get-->| OP | | | | User | the Questioned User's Statement | | | | +--------+ | | | | | | | |<---(3a) User Questioning Response-------------| | | | | | | |---(3b) Acknowledgement----------------------->| | +--------+ +--------+
The Client sends the User Questioning Request using HTTP POST. The Access Token obtained from an OAuth Authorization request MUST be sent as a Bearer Token. The User Questioning Request MUST contain a JSON object in the request body, with the following attributes. Attribute name Presence Type Description Example user_id FORBIDDEN if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User string Unique identifier allowing to identify the Questioned User (e.g. Mobile phone , sub, ...). Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. 3444975f-1137-47dc-908f-942ac85ab98f user_id_type FORBIDDEN if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User string Indicate the type of the End-User's identifier used for User Questioning. Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. Possible values are described in . MSISDN question_to_display MANDATORY string Question to be displayed to the Questioned User. An example message to display wished_qcr MANDATORY string Questioning context class reference : Level of Assurance wished by the Client (can be 2 3 4). 3 wished_qmr OPTIONAL string Questioning method wished by the Client SMS_OTP client_notification_endpoint MANDATORY uri URL exposed by the Client's backend to receive a notification from OP when a User Questioning is finished (accepted, denied, error...). Needed if the Client wants to use Pushed-To-Client Flow (See ). https://client.example.com/questions
This example describes a context where the access_token is tied with a specific End-User. If the Client add user_id / user_id_type in the request, these parameters will be ignored. The following is a non-normative example.
POST /questions HTTP/1.1 Host: server.example.com Content-Type: application/json Accept: application/json Authorization: Bearer SlAV32hkKG { "question_to_display":"An example message to display", "wished_qcr":"3", "client_notification_endpoint":"https://server.client.com/questions" }
This example describes a context where the access_token is not tied with a specific End-User. The Client MUST add user_id and user_id_type in the request. The following is a non-normative example.
POST /questions HTTP/1.1 Host: server.example.com Content-Type: application/json Accept: application/json Authorization: Bearer SlAV32hkKG { "user_id":"33612345678", "user_id_type":"MSISDN", "question_to_display":"An example message to display", "wished_qcr":"3", "client_notification_endpoint":"https://server.client.com/questions" }
The Client receives a HTTP 201 Created response. The response body contains a JSON object with the following attributes. Parameter name Presence Type Description Example id MANDATORY string Unique identifier of the Question. 984dcc7d-3d4d-4b0f-9f80-22e344f9a956 status MANDATORY string Status code of the Question (note that Error codes are handled by the HTTP protocol). "pending" In this flow, there are two possible status in the received JSON object: This is the temporary status when the User Questioning Response is not ready. This is a temporary status when an additional verification_code is required. If the status is verification_code_required, then the current flow is the Terminated-By-Client Flow ().
The following is a non-normative example.
HTTP/1.1 201 Created Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"pending", }
The following is a non-normative example.
HTTP/1.1 201 Created Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"pending", }
The Client receives a HTTP 400 Bad Request as specified in .
The way the User Questioning Endpoint obtains the Questioned User's Statement for the Question is out of the scope of this specification.
The OP sends the User Questioning Response to the Client using HTTP POST. The User Questioning Response MUST contain a JSON object in the request body, with the following attributes. Attribute name Presence idMANDATORY statusMANDATORY creation_dateMANDATORY last_modification_dateMANDATORY statement_dateMANDATORY user_idOPTIONAL if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User user_id_typeOPTIONAL if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User question_displayedMANDATORY used_qcrMANDATORY used_qmrOPTIONAL ...any other...IGNORED In this flow, there are three possible status (cf. ) in the User Questioning Response: This is the final status when the End-User accepted the User Questioning Request. This is the final status when the End-User denied the User Questioning Request. This is the final status when there is an error. Refer to for more details.
The following is a non-normative example.
POST /questions HTTP/1.1 Host: server.client.com Accept: application/json { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"accepted", "creation_date":"1311281970", "last_modification_date":"1311282970", "statement_date":"1311282970", "question_displayed":"An example message to display", "used_qcr":"3", "used_qmr":"SIM_APPLET", }
The following is a non-normative example.
POST /questions HTTP/1.1 Host: server.client.com Accept: application/json { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"denied", "creation_date":"1311281970", "last_modification_date":"1311282970", "statement_date":"1311282970", "question_displayed":"An example message to display", "used_qcr":"3", "used_qmr":"SIM_APPLET", }
The Client receives a HTTP POST as specified in .
The acknowledgement MUST be a HTTP 200 OK. The HTTP code is the only parameter to consider. The rest of the HTTP response should be ignored.
The following is a non-normative example.
HTTP/1.1 200 OK
In this flow, after the first User Questioning Request, the Client must supply the OP with a verification_code in order to finish the User Questioning (accepted, denied, error...).
+--------+ +--------+ | |---(1a) User Questioning Request-------------->| | | | | | | |<--(1b) Question Created-----------------------| | | | | | | | +--------+ | | | | | |<--(2a) User interactions to get-->| | | | | End- | the Questioned User's Statement | | | | | User | | | | Client | | |<----(2b) Verification_code--------| OP | | | +--------+ | | | | | | | | |<-----+ (2c) Verification_code | | | | | | | |---(3a) Verification_code--------------------->| | | | | | | |<---(3b) User Questioning Response-------------| | +--------+ +--------+
The Client sends the User Questioning Request using HTTP POST. The Access Token obtained from an OAuth Authorization request MUST be sent as a Bearer Token. The User Questioning Request MUST contain a JSON object in the request body, with the following attributes. Attribute name Presence Type Description Example user_id FORBIDDEN if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User string Unique identifier allowing to identify the Questioned User (e.g. Mobile phone , sub, ...). Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. 3444975f-1137-47dc-908f-942ac85ab98f user_id_type FORBIDDEN if the access_token is tied with a End-User, MANDATORY if the access_token is not tied with a End-User string Indicate the type of the End-User's identifier used for User Questioning. Ignored if the Access Token is tied with a specific End-User, mandatory otherwise. Possible values are described in . MSISDN question_to_display MANDATORY string Question to be displayed to the Questioned User. An example message to display wished_qcr MANDATORY string Questioning context class reference : Level of Assurance wished by the Client (can be 2 3 4). 3 wished_qmr OPTIONAL string Questioning method wished by the Client SMS_OTP client_notification_endpoint IGNORED uri URL exposed by the Client's backend to receive a notification from OP when a User Questioning is finished (accepted, denied, error...). Needed if the Client wants to use Pushed-To-Client Flow (See ). https://client.example.com/questions
This example describes a context where the access_token is tied with a specific End-User. If the Client add user_id / user_id_type in the request, these parameters will be ignored. The following is a non-normative example.
POST /questions HTTP/1.1 Host: server.example.com Content-Type: application/json Accept: application/json Authorization: Bearer SlAV32hkKG { "question_to_display":"An example message to display", "wished_qcr":"3" }
This example describes a context where the access_token is not tied with a specific End-User. The Client MUST add user_id and user_id_type in the request. The following is a non-normative example.
POST /questions HTTP/1.1 Host: server.example.com Content-Type: application/json Accept: application/json Authorization: Bearer SlAV32hkKG { "user_id":"33612345678", "user_id_type":"MSISDN", "question_to_display":"An example message to display", "wished_qcr":"3" }
The Client receives a HTTP 201 Created response. The response body contains a JSON object with the following attributes. Parameter name Presence Type Description Example id MANDATORY string Unique identifier of the Question. 984dcc7d-3d4d-4b0f-9f80-22e344f9a956 status MANDATORY string Status code of the Question (note that Error codes are handled by the HTTP protocol). "pending" In this flow, there are two possible status in the JSON object received: This is the temporary status when the User Questioning Response is not ready. If the status is "pending", then the current flow is either the Pulled-By-Client Flow () or the Pushed-To-Client Flow (). This is a temporary status when an additional verification_code is required. This is the normal status for this flow.
The following is a non-normative example.
HTTP/1.1 201 Created Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"verification_code_required", }
The following is a non-normative example.
HTTP/1.1 201 Created Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"verification_code_required", }
The Client receives a HTTP 400 Bad Request as specified in .
The way the User Questioning Endpoint obtains the Questioned User's Statement for the Question is out of the scope of this specification.
The way the User Questioning Endpoint sends the verification_code to the Questioned User is out of the scope of this specification.
The way the End-User sends the verification_code to the Client is out of the scope of this specification.
The Client sends the verification_code to the OP using HTTP PUT. The Access Token obtained from an OAuth Authorization request MUST be sent as a Bearer Token. The HTTP request MUST contain the following attribute, form serialized in the body for the HTTP PUT method. Attribute name Presence verification_codeMANDATORY ...any other...IGNORED
The following is a non-normative example.
PUT /questions/84c1d9d6-62e5-4803-ac0e-36b858c HTTP/1.1 Host: server.example.com Accept: application/x-www-form-urlencoded Content-Type: application/json Authorization: Bearer SlAV32hkKG verification_code=12345
The Client receives the User Questioning Response in a HTTP 200 OK response. The successful User Questioning Response MUST contain a User Statement Token in the response body .
The following is a non-normative example.
HTTP/1.1 200 OK Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "status":"accepted", "creation_date":"1311281970", "last_modification_date":"1311282970", "statement_date":"1311282970", "question_displayed":"An example message to display", "used_qcr":"2", "used_qmr":"SMS_OTP" }
The following is a non-normative example.
HTTP/1.1 200 OK Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "status":"denied", "creation_date":"1311281970", "last_modification_date":"1311282970", "statement_date":"1311282970", "question_displayed":"An example message to display", "used_qcr":"2", "used_qmr":"SMS_OTP" }
The Client receives a HTTP 400 Bad Request as specified in .
error_info is a JSON object which contains the following properties : Value Description Example error_code REQUIRED. Code representing the error. See section for possible values. unknown_user error_description OPTIONAL. Human-readable ASCII encoded text description of the error. The user is unknown error_uri OPTIONAL. URI of a web page that includes additional information about the error. https://server.example.com/errors/unknown_user
error_code is a property of the error_info Object. It can takes the following values : Value Description unknown_user The Questioned User is unknown. timeout The User Questioning has expired (timeout - no action from Questioned User). verification_code_failed The verification_code provided was not correct. verification_code_too_many_tries The verification_code has already been check without success several times (the number of time is up to the OP).
The Client receives the error in a HTTP 400 Bad Request. The response body contains a JSON object with the following attributes. Parameter name Presence Type Description Example error_info MANDATORY JSON Object See . {"error_code":"unknown_user"}
This example can occur in the Pulled-By-Client (cf. ), Pushed-To-Client (cf. ) and Terminated-By-Client (cf. ) flows. The following is a non-normative example.
HTTP/1.1 400 Bad Request Content-Type: application/json Content-Location: https://server.example.com/questions/84c1d9d6-62e5-4803-ac0e-36b858c Content-Length: xxx { "error_info": { "error_code":"unknown_user", "error_description":"The user is unknown", "error_uri":"https://server.example.com/errors/unknown_user" } }
The Client receives the error in a HTTP POST. The request body contains a JSON object with the following attributes. Parameter name Presence Type Description Example id MANDATORY string Unique identifier of the Question. 984dcc7d-3d4d-4b0f-9f80-22e344f9a956 status MANDATORY string Status code of the Question. "error" error_info MANDATORY JSON Object See . {"error_code":"unknown_user"}
This example can occur in the Pushed-To-Client flow (cf. ). The following is a non-normative example.
POST /questions HTTP/1.1 Host: server.client.com Accept: application/json { "id":"84c1d9d6-62e5-4803-ac0e-36b858c", "status":"error", "error_info": { "error_code":"unknown_user", "error_description":"The user is unknown", "error_uri":"https://server.example.com/errors/unknown_user" } }
cf. OpenID Connect - chapter 10
TBD
TBD
This document makes no requests of IANA.
OpenID Connect Standard 1.0 Nomura Research Institute, Ltd. Ping Identity Microsoft Google Salesforce Illumila OpenID Connect Dynamic Client Registration 1.0 Nomura Research Institute, Ltd. Ping Identity Microsoft OpenID Connect Discovery 1.0 Nomura Research Institute, Ltd. Ping Identity Microsoft Illumila JSON Web Token (JWT) Microsoft Ping Identity Nomura Research Institute, Ltd.
The following have contributed to the development of this specification.
Copyright (c) 2014 The OpenID Foundation. The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
[[ To be removed from the final specification ]] -01 Initial draftAdded OIDF Standard Notice