The Mobile Connect APIs support 9 products across four services: + +
Simple and globally ubiquitous user + Authentication.
User Authorisation of Service Provider requests
The provision of user Identity
Insights about the user, their device + or a transaction
Operator ID Gateway implementations will be based on specific Mobile + Connect profiles. There may be some differences across + operators although the implementations will normally be consistent within + a country. Please see the country + specific variations pages for more information.
+ +Details of the technical differences will be discussed in the product + specific implementation guides. You can find more information on different the + Mobile Connect Profiles page.
+ - name: AUTHENTICATION + description: >- +Mobile Connect Authentication offers a simple and globally ubiquitous + log-in mechanism with no personal information being shared without the + end-user's permission.
+ +Before you can make an live authentication request you need to ensure that the + following pre-requisites have been completed
+ +You have obtained Operator endpoints and credentials.
+ +The Operator Mobile Connect endpoints and credentials can be retrieved + using the Discovery service or will be provided to you if + you are working directly with an operator.
+ +Access to the operator ID Gateway is confirmed
+ +You should have received confirmation (either via Mobile Connect
+ Support or directly from the operator) that your credentials have been
+ enabled on the operator ID Gateway - note that this will include the
+ redirect_uri that you will be using and have registered with
+ the Developer Portal or provided to the operator.
You can, of course, use the Sandbox at any time.
+ +There are a number of different Mobile Connect Profiles, a full description + of the profiles can be found here. + You will need to understand which version an operator uses before you implement + authentication. The parameter descriptions below indicate the differences between the profiles + and how they impact authentication.
+ +As Mobile Connect is based on OpenID Connect, at a high level Authentication is a two stage process:
+ +code received from the authorize
+ request to get an ID Token. The customer identifer (PCR) can then be extracted
+ from the token to identify the end-user.The diagram below breaks down these steps in more detail
+ +
+
+
+ code extracted from the authorize response.
+ The PCR can now be used to to identify a returning end-user or to set up an account for a new user.
+ - name: AUTHORISATION + description: >- +Mobile Connect Authorise captures authorisation from a user for a service provider + to perform an action on their behalf. The service provider provides details specific + to their request in the Mobile Connect API, which is displayed on the user’s mobile phone. + The user approves or rejects the request, which is relayed to the service provider + in the API response. The user is authenticated as part of the flow to ensure that + they have the right to provide the authorisation.
+ +Mobile Connect Authorise Plus works in the same way, but in addition, requires + the end user to authenticate first by entering the Mobile Connect PIN prior to + authorising the request.
+ +The diagram below breaks down these steps in more detail
+ +
+
+
+ Identity is supported by Mobile Connect Profile v2.0 and Mobile Connect Profile DI v2.3
+ + + + - name: SIGN-UP + description: >- +Mobile Connect Sign-up allows end-users to consent to share details necessary to sign-up for a service.
+ +Sign-up is supported by Mobile Connect Profile v2.0 and Mobile Connect Profile DI v2.3
+ + - name: PHONE NUMBER + description: >- +Mobile Connect Phone Number allows end-users to consent to share their Phone Number.
+ +Phone Number is supported by Mobile Connect Profile v2.0 and Mobile Connect Profile DI v2.3
+ + - name: NATIONAL ID + description: >- +Mobile Connect National ID allows end-users to consent to share their National ID
+ +National ID is supported by Mobile Connect Profile v2.0 and Mobile Connect Profile DI v2.3
+ + - name: KYC MATCH + description: >- ++ +
KYC Match provides a mechanism for Service Providers to receive feedback + from an operator on key parameters associated with a user’s mobile device account + to prevent it being used as part of an Service Provider account takeover attack. + This mechanism is based on comparing the data held by the Service Provider with + that held by the operator. The actual data compared will be implementation specific + but the underlying mechanism does not change.
+ +KYC is provided in a two flavours:
+ +The latter approach ensures that the Operator and the TSP do not learn anything new about the user.
+ ++ +
Before you can make a live authentication request you need to ensure that the + following pre-requisites have been completed
+ +You have obtained Operator endpoints and credentials.
+ +The Operator Mobile Connect endpoints and credentials can be retrieved + using the Discovery service or will be provided to you if + you are working directly with an operator.
+ +Access to the operator ID Gateway is confirmed
+ +You should have received confirmation (either via Mobile Connect
+ Support or directly from the operator) that your credentials have been
+ enabled on the operator ID Gateway - note that this will include the
+ redirect_uri and sector_identifier_uri that you will be
+ using and have registered with the Developer Portal or provided to the operator.
You can, of course, use the Sandbox at any time.
+ ++ +
There are two possible approaches to using attributes in KYC Match
+ ++ +
The following attributes are available in KYC Match.
+ +These attributes provide the users name.
+ +given_name Given name(s) or first name(s) of the end-user.family_name Family name(s), surname(s) or last name(s) of the end-user./li>
+ name Concatenated attribute of given_name and first_name.These attributes provide the users address.
+ +houseno_or_housename End-user's registered house number or house name.postal_code End-user's registered zip code or post code.town End-user's registered city or town name.country End-user's registered country.address Concatenated attribute of houseno_or_housename, postal_code, town and country.Attributes other name name or address.
+ +birthdate End-User's birthday, represented as an ISO 8601:2004 [ISO8601 2004] YYYY-MM-DD format. The year may be 0000, indicating that it is omitted.+ +
The response match values indicate if there has been a match. If the match fails then the response will indicate the reason.
+ +| Response | +Description | +
|---|---|
| Y | +Match is successful | +
| N-NA | +Match failed. Data is not available. | +
| N-AV | +Match failed. Data is available. | +
| N-AD | +Match failed. Data is available, but access is denied. | +
+ +
KYC Match is only supported as part of Mobile Connect v2.3 and operators are free to decide which variant of the KYC Match service they wish to support.
+ +The KYC Match service MAY issue a notification to the end user if it receives a request from a TSP with Level2 trusted status (i.e., where the TSP has already captured consent); doing so ensures that the user is aware that the KYC Match service has been invoked against their MSISDN
+ +Mobile Connect KYC Match normalization rules for attributes should be negotiated offline between Operators and SPs for a given geographic region / market..
+ - name: ERROR HANDLING + description: >- + +Mobile Connect defines various error messages based on different scenarios that + will be returned to the Service Provider. These error messages are related to:
+ +If authorization request contains a state parameter, then the error response MUST + contain "state “parameter value. The value is set to the value received from the + Service Provider. If correlation_id is provided in the authorization request, + then it must be included in the response, and the value must be set to the value + received from the Service Provider.>/p> + +
The following is the example error response.
+ ++ HTTP/1.1 302 Found + Location: https://sp.example.org/redirct_here + ?error=invalid_request + &error_description=Invalid%20response_type%20value + &state=af0ifjsldkj + &correlation_id=+ ++
+ +
If redirect_uri is missing or redirect_uri value is invalid, then Operator ID + Gateway will always treat this as a high priority error and MUST return the + appropriate error response as described in the following table.
+ +| HTTP Response | +Error Code | +Error Description | +Scenario | +
|---|---|---|---|
| 400 Bad request | +invalid_request | +redirect_uri is invalid | +The redirect_uri value is invalid or not a registered URI. | +
| 302 Found | +access_denied | +Unknown user | +MSISDN/ENCR MSISDN/ PCR provided does not belong to the Operator. | +
| 302 Found | +access_denied | +User is not recognized | +MSISDN/ENCR MSISDN/ PCR provided does not belong to the Operator. | +
| 302 Found | +access_denied | +Mobile Connect User is not registered | +MSISDN/MSISDN belongs to the Operator, but MC services are not enabled. + Note: IDGW policy does not allow creation of partially active accounts. | +
| 302 Found | +access_denied | +Unknown Mobile Connect User | +MSISDN/ENCR_MSISDN belongs to the Operator, but MC services are not enabled. + Note: IDGW policy does not allow creation of partially active accounts. | +
| 302 Found | +temporarily_unavailable | +Internal Server Error | +System connection problems [internal to IDGW] (or) + Authenticator unreachable (or) + Expiration in server (or) + Any Unexpected error [internal to IDGW] + | +
| 302 Found | +server_error | +Internal Server Error | +System connection problems [internal to IDGW] (or) + Authenticator unreachable (or) + Expiration in server (or) + Any Unexpected error [internal to IDGW] + | +
| 302 Found | +access_denied | +The user is busy with another transaction | +Multiple requests for the same MSISDN sent at the same time. | +
| 302 Found | +invalid_request | +MANDATORY parameter response_type is missing or value is invalid | +The response_type parameter is missing or invalid. | +
| 302 Found | +invalid_request | +MANDATORY parameter client_id is missing | +The client_id parameter value is invalid. | +
| 302 Found | +invalid_request | +The client is not authorized to request an authorization code | +The client_id is valid, but not allowed to make MC service requests | +
| 302 Found | +access_denied | +The client is not allowed to make MC service requests | +The client_id is valid, but not allowed to make MC service requests. | +
| 302 Found | +unauthorized_client | +The client is not allowed to make MC service requests | +The client_id is valid, but not allowed to make MC service requests. | +
| 302 Found | +invalid_request | +MANDATORY parameter scope is missing | +The scope parameter is missing. | +
| 302 Found | +invalid_request | +The scope value is invalid | +The scope value "openid" is missing (or) + invalid scope values. + |
+
| 302 Found | +invalid_scope | +MANDATORY parameter scope is missing | +The scope parameter is missing. | +
| 302 Found | +invalid_scope | +The scope value is invalid | +The scope value "openid" is missing (or) + invalid scope values. + |
+
| 302 Found | +invalid_request | +MANDATORY parameter version is missing / invalid. | +The version parameter is missing (or) + version parameter value is invalid. |
+
| 302 Found | +invalid_request | +RECOMMENDED parameter state is invalid | +The state parameter exists, but the value is invalid. | +
| 302 Found | +invalid_request | +MANDATORY parameter nonce is missing (or) invalid. | +nonce parameter is missing (or) nonce parameter exists, but the value is empty |
+
| 302 Found | +invalid_request | +MANDATORY parameters login_hint_token (or) login_hint does not exist. | +login_hint and login_hint_token parameters are missing +Note: In the following conditions the IDGW SHOULD prompt the user to input MSISDN instead of throwing an error; |
+
| 302 Found | +invalid_request | +Malformed request, duplicate parameter entries | +login_hint and login_hint_token both exist. | +
| 302 Found | +invalid_request | +Invalid value for login_hint or login_hint_token | +The login_hint (or) login_hint_token value is invalid | +
| 302 Found | +invalid_request | +MANDATORY parameter acr_values are missing or invalid values. | +The acr_values parameter is missing (or) + acr_values exist but contains an invalid value, other than supported values + |
+
| 302 Found | +invalid_request | +Invalid display value. / not supported. | +display parameter exists and it has an invalid value (or) + display parameter exists and IDGW does not support the requested value + |
+
| 302 Found | +invalid_request | +Multiple parameter names in the authorization request. Malformed request | +The same parameter exists multiple times. | +
| 302 Found | +invalid_request | +Prompt value is invalid | +prompt value exists, and it has an invalid value. | +
| 302 Found | +invalid_request | +claims value is invalid, | +claims parameter exists, but it does not contain any value (or) + claims parameter exists, but it has invalid values. |
+
| 302 Found | +invalid_request | +GET request invalid serialization | +GET request is used, and the request parameter is NOT serialized using URI string serialization, IDGW able to validate the redirect_uri. | +
| 302 Found | +invalid_request | +POST request Invalid serialization | +POST request is used, the request parameters are NOT serialized using form serialization, IDGW can validate the redirect_uri. | +
| 302 Found | +invalid_request | +response_mode contains same as response_type (or) invalid | +response_mode parameter exists, and it has a value not supported by the Operator IDGW. | +
| 302 Found | +invalid_request | +Invalid max_age value | +max_age parameter exists, and it has an invalid value. | +
| 302 Found | +invalid_request | +Malformed request multiple problems exist | +Multiple problems in authorization request [redirect URI is valid]. | +
| 302 Found | +invalid_request | +Invalid correlation_id value. | +correlation_id exists, but it has an empty value | +
| 302 Found | +invalid_request | +Invalid client_name value | +client_name exists but it has empty value (or) + client_name parameter exists, but the provided value is not a registered client_name with Operator IDGW and invalid. + |
+
NOTE: the error messages defined above only apply to Mobile Connevt DI v2.3.
+######################################################################################### +# CALL DEFINITIONS +######################################################################################### +host: operator.com +paths: +######################################################################################### +# AUTHENTICATION +######################################################################################### + /authorize?[Authentication-params]: + get: + tags: + - AUTHENTICATION + summary: Authorize + description: >- +Requests that the operator ID Gateway authenticate an end-user and return a + value which can be used to make the Get Tokens call.
+ +Once the user has selected the Mobile Connect button the application should open + up a pop-up window or web view. The application will load this window with the + authorise request. A successful authorise request will result in a 302 Found response from + the operator ID Gateway where the Location header will point to the operator wait screen. This + screen displays a message to the end-user that a message has been sent to their device + using the operator's selected authenticator. + (You can see this in the Sandbox where an SMS wait screen is displayed).
+ +Once the end-user has authenticated themselves another 302 Found
+ is returned to the redirect_uri
+ passed in the initial request (and previously registered with the operator ID gateway).
+ The response will have a number of URI parameters which are used to build the
+ follow-up Get Tokens call
The URI response parameters are:
+ +code: Authorization code as per OAuth 2.0 section 4.1.2. This code will be used in the Get Token call.state: This must equal the state parameter in the initial Authenticate User request.correlation_id: If the initial request included a correlation_id then this will be included. Not
+ supported for Mobile Connect Profile v1.1.If there are issues with the request the response will be + 400 Bad Request. All other errors will be provided as part of the + 302 Found response, with URI parameters in the format:
+ +error: Error type.error_description: Description of the error.Error responses will vary according to the Mobile Connect Profile. More + details on error responses can be found here.
+ +
+
+ The This parameter is required for all Mobile Connect Profiles The URI to which ID Gateway responses are sent.
+ The This parameter is required for all Mobile Connect Profiles Indicates the grant
+ type (i.e. method). The value must always be This parameter is required for all Mobile Connect Profiles Space delimited, case-sensitive ASCII, strings of the scope values used to indicate
+ the services being requested. For more information see the
+ Scope values
+ page. For Mobile Connect Profile v1.1 Authentication requests the scope values should be
+ For all other Mobile Connect Authentication requests the scope values should be
+ This parameter is required for all Mobile Connect Profiles This parameter identifies the Mobile Connect profile version. This parameter is required for Mobile Connect DI Profile v2.3
+ ( Value used by the client to maintain state between request and callback.
+ Also used as a security mechanism , if a cryptographic binding is done with
+ the browser cookie, to prevent Cross-Site Request Forgery. The recommended
+ format is UUID4. This parameter is required for all Mobile Connect Profiles. String value used to associate a client session with the ID Token.
+ It is passed unmodified from Authorisation Request to ID Token. The value
+ SHOULD be unique per session to mitigate replay attacks. The recommended
+ format is UUID4. This parameter is required for all Mobile Connect Profiles. Specifies the user interface display for the Authentication and Consent flow. Values are: These values will only be respected if supported by the ID Gateway. This is an optional parameter supported by all Mobile Connect Profiles. Specifies to the IDGW Server whether to prompt the end-user for re-authentication and consent. Values are: This is an optional parameter supported by all Mobile Connect Profiles. Indicator of the maximum elapsed time in seconds since the last
+ authentication of the end-user. If the elapsed time is greater than
+ this value, a re-authentication must be done. When this parameter is
+ in present the request, the ID Token will contain the
+ This parameter is optional for Mobile Connect DI Profile v2.3 and Mobile
+ Connect Profile v.2.0. It is recommended for Mobile Connect Profile v1.1. Space separated list of user preferred languages and scripts for
+ the UI as per RFC5646. The parameter is for guidance only and in
+ case a requested locale is not supported then the user interface
+ will be provided in the default language of the ID Gateway. This is an optional parameter supported by all Mobile Connect
+ Profiles Space separated list of user preferred languages and scripts for
+ the claims, defines as per RFC5646. The parameter is for guidance
+ only and in case a requested locale is not supported then the claims
+ will be provided in the default language of the ID Gateway. This is an optional parameter supported by all
+ Mobile Connect Profiles Previously issued ID token passed as a hint for the current or past
+ authentication session, generally used in conjunction with
+ This is an optional parameter supported by all Mobile Connect Profiles. An indication to the ID Gateway about what ID to use for login. Using this
+ parameter allows the end-user to skip the login identifier. The values passed
+ will be a type and associated value (see example). This is an optional parameter supported by all Mobile Connect Profiles. Encrypted JSON Web Token (JWT) that contains a user hint
+ about the SP for an individual Mobile
+ Network Operator (MNO). The This parameter is optional for Mobile Connect DI Profile
+ v2.3 and Mobile Connect Profile v2.0. and is not
+ supported by Mobile Connect Profile v1.1 Level of Assurance to be used to authenticate an end-user. The values appear
+ as order of preference. The This parameter is required for all Mobile Connect Profiles. Informs the ID Gateway of the mechanism to be used for returning
+ parameters from the Authorize Endpoint. Can be used when there is
+ no user agent This parameter is optional for Mobile Connect DI Profile v2.3. It is
+ not supported by Mobile Connect Profile v2.0 and Mobile Connect Profile 1.1 Correlates a transaction across Mobile Connect components. The value is generated by the Service Provider
+ and must be locally unique. This parameter should be used in conjunction
+ with your operator partner and only for tracing and resolving issues. If you are using the Discovery service then you should use the same correlation ID
+ that you use in the Discovery call. The recommended format is UUID4. This parameter is optional for Mobile Connect DI Profile
+ v2.3 and Mobile Connect Profile v2.0. and is not
+ supported by Mobile Connect Profile v1.1 This is a text string to be signed with the private key owned by the
+ SIM card of the end-user. The signed data is returned in the ID
+ Claim, as private JWT claims for this profile. This parameter is only supported by Mobile Connect Profile 1.1 The resource requested has been temporarily moved to the URL given
+ by the Location header. This will be the location of the MNO wait screen
+ that tells the end-user that they have been sent a message and should
+ respond to it. Returns a signed ID Token and an
+ Access Token when passed the code value
+ returned from a previous authorize request. The Access Token is used to access further protected resources, but for
+ Authentication we only need the ID Token as this contains the
+ end-user PCR. To access this the ID Token will need to be
+ decoded, validated and verified. Full details on this process can be found on
+ the tokens page. The PCR is your user identifier and will be consistent for each request.
+ It should be stored against the end-user’s account. Unless specified in the parameter descriptions all parameters apply to
+ Mobile Connect Profile v1.1, Mobile Connect v2.0 & Mobile Connect Profile DI v2.3 Describes the method to be used for the
+ processing flow. The value of this parameter must always be
+ Authorisation code received from the ID Gateway as a result of the
+ successful Authorize request. Allows the SP to obtain the Access Token
+ and the ID Token from the ID Gateway. URI to which the responses from the ID Gateway are sent. The value of this
+ parameter must match that sent in the authorise request. The same This parameter is optional for Mobile Connect DI Profile
+ v2.3 and Mobile Connect Profile v2.0. and is not
+ supported by Mobile Connect Profile v1.1 Uses HTTP basic
+ authentication to access the API. This is a Base64 encoded
+ string of your Requests that the operator ID Gateway capture an end-user authorisation to
+ allow the SP to perform an action on their behalf and returns values which can be used to make the
+ Get Tokens
+
+ Once the user has selected the Mobile Connect button and the application has
+ opened a pop-up or web-view then the browser will make the Authorize request
+ using a 302 Found sent from the SP application. A successful
+ request will result in a 302 Found response from
+ the operator ID Gateway where the location will point the operator wait screen. This
+ screen displays a message to the end-user that a message has been sent to their device
+ using the operator's selected authenticator.
+ (You can see this in the Sandbox where an SMS wait screen is displayed). Once the end-user has authorised the transaction a 302 Found
+ is returned to the The URI response parameters are: If there are issues with the request the response will be
+ 400 Bad Request. All other errors will be provided as part of the
+ 302 Found response, with URI parameters in the format: Error responses will vary according to the Mobile Connect Profile. More
+ details on error responses can be found here.
+
+
+
+ The The URI to which ID Gateway responses are sent.
+ The Indicates the grant
+ type (i.e. method). The value must always be Space delimited, case-sensitive ASCII, strings of the scope values used to indicate
+ the services being requested. For more information see the
+ Scope values
+ page. This parameter identifies the Mobile Connect profile version. Value used by the client to maintain state between request and callback.
+ Also used as a security mechanism, if a cryptographic binding is done with
+ the browser cookie, to prevent Cross-Site Request Forgery. The recommended
+ format is UUID4. String value used to associate a client session with the ID Token.
+ It is passed unmodified from Authorisation Request to ID Token. The value
+ SHOULD be unique per session to mitigate replay attacks. The recommended
+ format is UUID4. Specifies the user interface display for the Authentication and Consent flow. Values are: These values will only be respected if supported by the ID Gateway. Specifies to the IDGW Server whether to prompt the end-user for re-authentication and consent. Values are: This is an optional parameter supported by all Mobile Connect Profiles. Indicator of the maximum elapsed time in seconds since the last
+ authentication of the end-user. If the elapsed time is greater than
+ this value, a re-authentication must be done. When this parameter is
+ in present the request, the ID Token must contain the
+ Space separated list of user preferred languages and scripts for
+ the UI as per RFC5646. The parameter is for guidance only and in
+ case a requested locale is not supported then the user interface
+ will be provided in the default language of the ID Gateway. This is an optional parameter supported by all Mobile Connect
+ Profiles Space separated list of user preferred languages and scripts for
+ the claims, defines as per RFC5646. The parameter is for guidance
+ only and in case a requested locale is not supported then the claims
+ will be provided in the default language of the ID Gateway. Previously issued ID token passed as a hint for the current or past
+ authentication session, generally used in conjunction with
+ An indication to the ID Gateway about what ID to use for login. Using this
+ parameter allows the end-user to skip the login identifier. The values passed
+ will parameter type and the parameter value (see example). Encrypted JSON Web Token (JWT) that contains a user hint
+ about the SP for an individual Mobile
+ Network Operator (MNO). The Level of Assurance to be used to authenticate an end-user. The values appear
+ as order of preference. The Informs the ID Gateway of the mechanism to be used for returning
+ parameters from the Authorize Endpoint. Can be used when there is
+ no user agent This parameter is optional for Mobile Connect DI Profile v2.3.
+ It is not supported by Mobile Connect Profile v2.0> A short name to identify the SP client application which will
+ be displayed on end-user de vice during the authorisation flow. This
+ short name is created when the application is registered
+ on the Developer Portal. Client provided plain text, to interlock the consumption device
+ and authorisation device for a better
+ user experience. The message will be displayed on both devices. Empty values
+ are allowed (zero length). A transaction or action based message provided by the client Application
+ which will be displayed on the authentication device of the end-user. Correlates a transaction across Mobile Connect components. The value is generated by the Service Provider
+ and must be locally unique. This parameter should be used in conjunction
+ with your operator partner and only for tracing and resolving issues. If you are using the Discovery service then you should use the same correlation ID
+ that you use in the Discovery call. The recommended format is UUID4. The resource requested has been temporarily moved to the URL given
+ by the Location header. This will be the location of the MNO wait screen
+ that tells the end-user that they have been sent a message and should
+ respond to it. Returns an Access Token and a
+ signed ID Token when passed the code value
+ returned from a previous Authorize request. The Access Token is used to access further protected resources, but for
+ Authorisation we only need the ID Token as this contains the
+ end-user PCR. To access this the ID Token will need to be
+ decoded, validated and verified. Full details on this process can be found on
+ the tokens page. The PCR is your user identifier and will be consistent for each request.
+ It should be stored against the end-user’s account. Unless specified in the parameter descriptions all parameters apply to
+ Mobile Connect v2.0 & Mobile Connect Profile DI v2.3 Describes the method to be used for the
+ processing flow. The value of this parameter must always be
+ Authorisation code received from the ID Gateway as a result of the
+ successful Authorize request. Allows the SP to obtain the Access Token
+ and the ID Token from the ID Gateway. URI to which the responses from the ID Gateway are sent. The value of this
+ parameter must match that sent in the request. The same Uses HTTP basic
+ authentication to access the API. This is a Base64 encoded
+ string of your This
+ parameter is required for all Mobile Connect Profiles This parameter is required for all
+ Mobile Connect Profiles The The URI to which ID Gateway responses are sent.
+ The Indicates the grant
+ type (i.e. method). The value must always be Space delimited, case-sensitive ASCII, strings of the scope value used to indicate
+ the service being requested. For more information see the
+ Scope values
+ page. This parameter identifies the Mobile Connect profile version. This
+ parameter is required for Mobile Connect DI Profile v2.3
+ ( Value used by the client to maintain state between request and callback.
+ Also used as a security mechanism, if a cryptographic binding is done with
+ the browser cookie, to prevent Cross-Site Request Forgery. The recommended
+ format is UUID4. String value used to associate a client session with the ID Token.
+ It is passed unmodified from Authorisation Request to ID Token. The value
+ SHOULD be unique per session to mitigate replay attacks. The recommended
+ format is UUID4. Specifies the user interface display for the Authentication and Consent flow. Values are: These values will only be respected if supported by the ID Gateway. Specifies to the IDGW Server whether to prompt the end-user for re-authentication and consent. Values are: Indicator of the maximum elapsed time in seconds since the last
+ authentication of the end-user. If the elapsed time is greater than
+ this value, a re-authentication must be done. When this parameter is
+ in present the request, the ID Token must contain the
+ Space separated list of user preferred languages and scripts for
+ the UI as per RFC5646. The parameter is for guidance only and in
+ case a requested locale is not supported then the user interface
+ will be provided in the default language of the ID Gateway. Space separated list of user preferred languages and scripts for
+ the claims, defines as per RFC5646. The parameter is for guidance
+ only and in case a requested locale is not supported then the claims
+ will be provided in the default language of the ID Gateway. Previously issued ID token passed as a hint for the current or past
+ authentication session, generally used in conjunction with
+ An indication to the ID Gateway about what ID to use for login. Using this
+ parameter allows the end-user to skip the login identifier. The values passed
+ will parameter type and the parameter value (see example). Encrypted JSON Web Token (JWT) that contains a user hint
+ about the SP for an individual Mobile
+ Network Operator (MNO). The Level of Assurance to be used to authenticate an end-user. The values appear
+ as order of preference. The Informs the ID Gateway of the mechanism to be used for returning
+ parameters from the Authorize Endpoint. Can be used when there is
+ no user agent This parameter is not supported by Mobile Connect Profile v2.0> A short name to identify the SP client application which will
+ be displayed on end-user de vice during the authorisation flow. This
+ short name is created when the application is registered
+ on the Developer Portal. Client provided plain text, to interlock the consumption device
+ and authorisation device for a better
+ user experience. The message will be displayed on both devices. Empty values
+ are allowed (zero length). A transaction or action based message provided by the client Application
+ which will be displayed on the authentication device of the end-user. Correlates a transaction across Mobile Connect components. The value is generated by the Service Provider
+ and must be locally unique. This parameter should be used in conjunction
+ with your operator partner and only for tracing and resolving issues. If you are using the Discovery service then you should use the same correlation ID
+ that you use in the Discovery call. The recommended format is UUID4. The resource requested has been temporarily moved to the URL given
+ by the Location header. This will be the location of the MNO wait screen
+ that tells the end-user that they have been sent a message and should
+ respond to it. Describes the method to be used for the
+ processing flow. The value of this parameter must always be
+ Authorization code received from the ID Gateway as a result of the
+ successful Authorize request. Allows the SP to obtain the Access Token
+ and the ID Token from the ID Gateway. URI to which the responses from the ID Gateway are sent. The value of this
+ parameter must match that sent in the request. The same Uses HTTP basic
+ authentication to access the API. This is a Base64 encoded
+ string of your Uses an Access Token to access the Premiuminfo resources. The token is of type The The URI to which ID Gateway responses are sent.
+ The Indicates the grant
+ type (i.e. method). The value must always be Space delimited, case-sensitive ASCII, strings of the scope values used to indicate
+ the services being requested. For more information see the
+ Scope values
+ page. This parameter identifies the Mobile Connect profile version. This
+ parameter is required for Mobile Connect DI Profile v2.3
+ ( Value used by the client to maintain state between request and callback.
+ Also used as a security mechanism, if a cryptographic binding is done with
+ the browser cookie, to prevent Cross-Site Request Forgery. The recommended
+ format is UUID4. String value used to associate a client session with the ID Token.
+ It is passed unmodified from Authorisation Request to ID Token. The value
+ SHOULD be unique per session to mitigate replay attacks. The recommended
+ format is UUID4. Specifies the user interface display for the Authentication and Consent flow. Values are: These values will only be respected if supported by the ID Gateway. Specifies to the IDGW Server whether to prompt the end-user for re-authentication and consent. Values are: Indicator of the maximum elapsed time in seconds since the last
+ authentication of the end-user. If the elapsed time is greater than
+ this value, a re-authentication must be done. When this parameter is
+ in present the request, the ID Token must contain the
+ Space separated list of user preferred languages and scripts for
+ the UI as per RFC5646. The parameter is for guidance only and in
+ case a requested locale is not supported then the user interface
+ will be provided in the default language of the ID Gateway. Space separated list of user preferred languages and scripts for
+ the claims, defines as per RFC5646. The parameter is for guidance
+ only and in case a requested locale is not supported then the claims
+ will be provided in the default language of the ID Gateway. Previously issued ID token passed as a hint for the current or past
+ authentication session, generally used in conjunction with
+ An indication to the ID Gateway about what ID to use for login. Using this
+ parameter allows the end-user to skip the login identifier. The values passed
+ will parameter type and the parameter value (see example). Encrypted JSON Web Token (JWT) that contains a user hint
+ about the SP for an individual Mobile
+ Network Operator (MNO). The Level of Assurance to be used to authenticate an end-user. The values appear
+ as order of preference. The Informs the ID Gateway of the mechanism to be used for returning
+ parameters from the Authorize Endpoint. Can be used when there is
+ no user agent This parameter is not supported by Mobile Connect Profile v2.0> A short name to identify the SP client application which will
+ be displayed on end-user de vice during the authorisation flow. This
+ short name is created when the application is registered
+ on the Developer Portal. Client provided plain text, to interlock the consumption device
+ and authorisation device for a better
+ user experience. The message will be displayed on both devices. Empty values
+ are allowed (zero length). A transaction or action based message provided by the client Application
+ which will be displayed on the authentication device of the end-user. Correlates a transaction across Mobile Connect components. The value is generated by the Service Provider
+ and must be locally unique. This parameter should be used in conjunction
+ with your operator partner and only for tracing and resolving issues. If you are using the Discovery service then you should use the same correlation ID
+ that you use in the Discovery call. The recommended format is UUID4. The resource requested has been temporarily moved to the URL given
+ by the Location header. This will be the location of the MNO wait screen
+ that tells the end-user that they have been sent a message and should
+ respond to it. Describes the method to be used for the
+ processing flow. The value of this parameter must always be
+ Authorization code received from the ID Gateway as a result of the
+ successful Authorize request. Allows the SP to obtain the Access Token
+ and the ID Token from the ID Gateway. URI to which the responses from the ID Gateway are sent. The value of this
+ parameter must match that sent in the request. The same Uses HTTP basic
+ authentication to access the API. This is a Base64 encoded
+ string of your Uses an Access Token to access the Premiuminfo resources. The token is of type The The URI to which ID Gateway responses are sent.
+ The Indicates the grant
+ type (i.e. method). The value must always be Space delimited, case-sensitive ASCII, strings of the scope values used to indicate
+ the services being requested. For more information see the
+ Scope values
+ page. This parameter identifies the Mobile Connect profile version. This
+ parameter is required for Mobile Connect DI Profile v2.3
+ ( Value used by the client to maintain state between request and callback.
+ Also used as a security mechanism, if a cryptographic binding is done with
+ the browser cookie, to prevent Cross-Site Request Forgery. The recommended
+ format is UUID4. String value used to associate a client session with the ID Token.
+ It is passed unmodified from Authorisation Request to ID Token. The value
+ SHOULD be unique per session to mitigate replay attacks. The recommended
+ format is UUID4. Specifies the user interface display for the Authentication and Consent flow. Values are: These values will only be respected if supported by the ID Gateway. Specifies to the IDGW Server whether to prompt the end-user for re-authentication and consent. Values are: Indicator of the maximum elapsed time in seconds since the last
+ authentication of the end-user. If the elapsed time is greater than
+ this value, a re-authentication must be done. When this parameter is
+ in present the request, the ID Token must contain the
+ Space separated list of user preferred languages and scripts for
+ the UI as per RFC5646. The parameter is for guidance only and in
+ case a requested locale is not supported then the user interface
+ will be provided in the default language of the ID Gateway. Space separated list of user preferred languages and scripts for
+ the claims, defines as per RFC5646. The parameter is for guidance
+ only and in case a requested locale is not supported then the claims
+ will be provided in the default language of the ID Gateway. Previously issued ID token passed as a hint for the current or past
+ authentication session, generally used in conjunction with
+ An indication to the ID Gateway about what ID to use for login. Using this
+ parameter allows the end-user to skip the login identifier. The values passed
+ will parameter type and the parameter value (see example). Encrypted JSON Web Token (JWT) that contains a user hint
+ about the SP for an individual Mobile
+ Network Operator (MNO). The Level of Assurance to be used to authenticate an end-user. The values appear
+ as order of preference. The Informs the ID Gateway of the mechanism to be used for returning
+ parameters from the Authorize Endpoint. Can be used when there is
+ no user agent This parameter is not supported by Mobile Connect Profile v2.0> A short name to identify the SP client application which will
+ be displayed on end-user de vice during the authorisation flow. This
+ short name is created when the application is registered
+ on the Developer Portal. Client provided plain text, to interlock the consumption device
+ and authorisation device for a better
+ user experience. The message will be displayed on both devices. Empty values
+ are allowed (zero length). A transaction or action based message provided by the client Application
+ which will be displayed on the authentication device of the end-user. Correlates a transaction across Mobile Connect components. The value is generated by the Service Provider
+ and must be locally unique. This parameter should be used in conjunction
+ with your operator partner and only for tracing and resolving issues. If you are using the Discovery service then you should use the same correlation ID
+ that you use in the Discovery call. The recommended format is UUID4. The resource requested has been temporarily moved to the URL given
+ by the Location header. This will be the location of the MNO wait screen
+ that tells the end-user that they have been sent a message and should
+ respond to it. Describes the method to be used for the
+ processing flow. The value of this parameter must always be
+ Authorization code received from the ID Gateway as a result of the
+ successful Authorize request. Allows the SP to obtain the Access Token
+ and the ID Token from the ID Gateway. URI to which the responses from the ID Gateway are sent. The value of this
+ parameter must match that sent in the request. The same Uses HTTP basic
+ authentication to access the API. This is a Base64 encoded
+ string of your Uses an Access Token to access the Premiuminfo resources. The token is of type The The URI to which ID Gateway responses are sent.
+ The The URI to which ID Gateway responses are sent.
+ The Space delimited, case-sensitive ASCII, strings of the scope values used to indicate
+ the services being requested. For more information see the
+ Scope values
+ page. JSON object listing specific claims to be returned in the response. Example JSON Object See the Claims specifications for more details. Identifies the Mobile Connect profile version. The
+ current version used for the deployment of KYC Match product is
+ Value used by the client to maintain state between request and callback.
+ Also used as a security mechanism , if a cryptographic binding is done with
+ the browser cookie, to prevent Cross-Site Request Forgery. The recommended
+ format is UUID4. String value used to associate a client session with the ID Token.
+ It is passed unmodified from Authorisation Request to ID Token. The value
+ SHOULD be unique per session to mitigate replay attacks. The recommended
+ format is UUID4. Specifies the user interface display for the Authentication and Consent flow. Values are: These values will only be respected if supported by the ID Gateway. Specifies to the IDGW Server whether to prompt the end-user for re-authentication and consent. Values are: This is an optional parameter supported by all Mobile Connect Profiles. Indicator of the maximum elapsed time in seconds since the last
+ authentication of the end-user. If the elapsed time is greater than
+ this value, a re-authentication must be done. When this parameter is
+ in present the request, the ID Token must contain the
+ Space separated list of user preferred languages and scripts for
+ the UI as per RFC5646. The parameter is for guidance only and in
+ case a requested locale is not supported then the user interface
+ will be provided in the default language of the ID Gateway. Space separated list of user preferred languages and scripts for
+ the claims returned as per RFC5646. The parameter is for guidance
+ only and in case a requested locale is not supported then the user
+ interface will be provided in the default language of the ID
+ Gateway. Previously issued ID token passed as a hint for the current or past
+ authentication session, generally used in conjunction with
+ An indication to the ID Gateway about what ID to use for login. Using this
+ parameter allows the end-user to skip the login identifier. The values passed
+ will parameter type and the parameter value (see example). This is an optional parameter supported by all Mobile Connect Profiles. Encrypted JSON Web Token (JWT) that contains a user hint
+ about the SP for an individual Mobile
+ Network Operator (MNO). The Level of Assurance to be used to authenticate an end-user. The values appear
+ as order of preference. The This parameter is required for all Mobile Connect Profiles. Informs the ID Gateway of the mechanism to be used for returning
+ parameters from the Authorize Endpoint. Can be used when there is
+ no user agent Short name of the SP's application / web service which can be
+ used for the end-user's authentication requests. This short name is
+ created when the SP registers their application / web service on the
+ Developers Portal. This parameter contains a transaction or action based message
+ which will be displayed on the authentication device of the
+ end-user. This message must be provided by the SP and should prompt
+ the end-user to give a consent to share data with the SP's
+ application / web-service The resource requested has been temporarily moved to the URL given
+ by the Location header. This will be the location of the MNO wait screen
+ that tells the end-user that they have been sent a message and should
+ respond to it. Describes the method to be used for the
+ processing flow. The value of this parameter must always be
+ Authorisation code received from the ID Gateway as a result of the
+ successful Authorize request. Allows the SP to obtain the Access Token
+ and the ID Token from the ID Gateway. URI to which the responses from the ID Gateway are sent. The value of this
+ parameter must match that sent in the request. The same Uses HTTP basic
+ authentication to access the API. This is a Base64 encoded
+ string of your Uses an Access Token to access the Premiuminfo resources. The token is of type Uses an Access Token to access the Premiuminfo resources. The token is of type Uses an Access Token to access the Premiuminfo resources. The token is of type Uses an Access Token to access the Premiuminfo resources. The token is of type This parameter
+ is required for all Mobile Connect Profiles This parameter is required for all Mobile Connect
+ Profiles This parameter is required for all Mobile Connect
+ Profilesclient_id field obtained from the Discovery response
+ which is used as the unique client identifier of the SPredirect_uri is defined during application
+ registration.code to
+ indicate the Authorisation Code Flow.openid
+
+ openid mc_authn
+
+ mc_di_r2_v2.3) and Mobile Connect Profile v2.0
+ (mc_v2.0). It is not supported by Mobile Connect Profile v1.1, but
+ mc_v1.1 can be used with ID Gateways that support Mobile
+ Connect Profiles v2.0 & SI v2.3 to ensure a v1.1 flow.page: The UI SHOULD be consistent with a full page view of the User-Agent.pop-up: Use a pop-up window. (The popup window SHOULD be 450px X 500px) touch: Display a UI consistent with a “touch” based interface.wap: The UI SHOULD be consistent with a “feature-phone” device displaynone: MUST NOT display any UI for reauthentication or consent to the user. If the user is not authenticated already, or authentication or consent is needed to process the Authorisation Request, a login_required error is returned. This can be used as a mechanism to check existing authentication or consent.no_seam: prompt the end-user if the authentication session is not valid. Caters for the 3G/4Ghot-spots, tethered phone etc. scenariosauth_time claim valueprompt=none. If the ID Token is still valid and the
+ end-user is logged in then the server returns a positive response,
+ otherwise will return a login_error response. For
+ the ID Token, the server does not need to be listed as audience,
+ when included in the id_token_hintlogin_hint_token should
+ be used by the SP as a login hint with the particular MNO, so the
+ MNO recognises the SP that is trying to get a response.acr used during authentication
+ is returned as acr claim value. When it is present the Authentication endpoint should satisfy one for the
+ end-user's authentication. The recommended values are the LOAs as
+ specified in ISO/IEC 29115
+ Clause 6 – 1, 2, 3, 4 – representing the LOAs of LOW, MEDIUM, HIGH and VERY HIGH.Handling the response
+
+ Mobile Connect Implementations
+
+ authorization_code.
+ x-example: authorization_code
+ - in: formData
+ name: code
+ type: string
+ required: true
+ description: >-
+ correlation_id submitted in the initial
+ authorize request.client_id:client_secretOverview
+
+ redirect_uri
+ passed in the initial request (and previously registered with the operator ID gateway).
+ The response will have a number of URI parameters which are used to build the
+ follow-up Get Tokens callResponse parameters
+
+
+
+
+ code: Authorization code as per OAuth 2.0 section 4.1.2. This code will be used in the Get Token call.state: This must equal the state parameter in the initial Authenticate User request.correlation_id: If the initial request included a correlation_id then this will be included. Not
+ supported for Mobile Connect Profile v1.1.Error responses
+
+
+
+
+ error: Error type.error_description: Description of the error.client_id field obtained from the Discovery response
+ which is used as the unique client identifier of the SPredirect_uri is defined during application
+ registration.code to
+ indicate the Authorisation Code Flow.page: The UI SHOULD be consistent with a full page view of the User-Agent.pop-up: Use a pop-up window. (The popup window SHOULD be 450px X 500px) touch: Display a UI consistent with a “touch” based interface.wap: The UI SHOULD be consistent with a “feature-phone” device displaynone: MUST NOT display any UI for reauthentication or consent to the user. If the user is not authenticated already, or authentication or consent is needed to process the Authorisation Request, a login_required error is returned. This can be used as a mechanism to check existing authentication or consent.no_seam: prompt the end-user if the authentication session is not valid. Caters for the 3G/4Ghot-spots, tethered phone etc. scenariosauth_time claim valueprompt=none. If the ID Token is still valid and the
+ end-user is logged in then the server returns a positive response,
+ otherwise SHOULD return a login_error response. For
+ the ID Token, the server does not need to be listed as audience,
+ when included in the id_token_hint
+ required: false
+ type: string
+ x-example: eyJhbGciOiJSUzI1NiIsImtpZCI6IjdlOGFkZmM
+ - in: query
+ name: login_hint
+ description: >-
+ login_hint_token should
+ be used by the SP as a login hint with the particular MNO, so the
+ MNO recognises the SP that is trying to get a response.acr using during authentication
+ is returned as acr claim value. This parameter is optional, however,
+ when it is present the Authentication endpoint should satisfy one of
+ them for end-user's authentication. The recommended values are the LOAs as
+ specified in ISO/IEC 29115
+ Clause 6 – 1, 2, 3, 4 – representing the LOAs of LOW, MEDIUM, HIGH and VERY HIGH.Handling the response
+
+ Mobile Connect Implementations
+
+ authorization_code.
+ x-example: authorization_code
+ - in: formData
+ name: code
+ type: string
+ required: true
+ description: >-
+ correlation_id submitted in the initial
+ authorize request. The correlation_id tracks the transaction
+ correlation across the Mobile Connect components (Discovery, Mobile
+ Connect). The value for this parameter is generated only by the SP and it
+ must be locally unique.client_id:client_secretclient_id field obtained from the Discovery response
+ which is used as the unique client identifier of the SPredirect_uri is defined during application
+ registration.code to
+ indicate the Authorisation Code Flow.mc_di_r2_v2.3) and Mobile Connect Profile v2.0 (mc_v2.0).page: The UI SHOULD be consistent with a full page view of the User-Agent.pop-up: Use a pop-up window. (The popup window SHOULD be 450px X 500px) touch: Display a UI consistent with a “touch” based interface.wap: The UI SHOULD be consistent with a “feature-phone” device displaynone: MUST NOT display any UI for reauthentication or consent to the user. If the user is not authenticated already, or authentication or consent is needed to process the Authorisation Request, a login_required error is returned. This can be used as a mechanism to check existing authentication or consent.no_seam: prompt the end-user if the authentication session is not valid. Caters for the 3G/4Ghot-spots, tethered phone etc. scenariosauth_time claim valueprompt=none. If the ID Token is still valid and the
+ end-user is logged in then the server returns a positive response,
+ otherwise server SHOULD return a login_error response. For
+ the ID Token, the server does not need to be listed as audience,
+ when included in the id_token_hint
+ required: false
+ type: string
+ x-example: eyJhbGciOiJSUzI1NiIsImtpZCI6IjdlOGFkZmM
+##### login_hint
+ - in: query
+ name: login_hint
+ description: >-
+ login_hint_token should
+ be used by the SP as a login hint with the particular MNO, so the
+ MNO recognises the SP that is trying to get a response.acr used during authentication
+ is returned as acr claim value. This parameter is optional, however,
+ when it is present the Authentication endpoint should satisfy one for the end-user's authentication. The recommended values are the LOAs as
+ specified in ISO/IEC 29115
+ Clause 6 – 1, 2, 3, 4 – representing the LOAs of LOW, MEDIUM, HIGH and VERY HIGH.authorization_code.
+ x-example: authorization_code
+##### code
+ - in: formData
+ name: code
+ type: string
+ required: true
+ description: >-
+ correlation_id submitted in the initial
+ authorize request. The correlation_id tracks the transaction
+ correlation across the Mobile Connect components (Discovery, Mobile
+ Connect). The value for this parameter is generated only by the SP and it
+ must be locally unique.client_id:client_secretBearerclient_id field obtained from the Discovery response
+ which is used as the unique client identifier of the SPredirect_uri is defined during application
+ registration.code to
+ indicate the Authorisation Code Flow.mc_di_r2_v2.3) and Mobile Connect Profile v2.0 (mc_v2.0).page: The UI SHOULD be consistent with a full page view of the User-Agent.pop-up: Use a pop-up window. (The popup window SHOULD be 450px X 500px) touch: Display a UI consistent with a “touch” based interface.wap: The UI SHOULD be consistent with a “feature-phone” device displaynone: MUST NOT display any UI for reauthentication or consent to the user. If the user is not authenticated already, or authentication or consent is needed to process the Authorisation Request, a login_required error is returned. This can be used as a mechanism to check existing authentication or consent.no_seam: prompt the end-user if the authentication session is not valid. Caters for the 3G/4Ghot-spots, tethered phone etc. scenariosauth_time claim valueprompt=none. If the ID Token is still valid and the
+ end-user is logged in then the server returns a positive response,
+ otherwise server SHOULD return a login_error response. For
+ the ID Token, the server does not need to be listed as audience,
+ when included in the id_token_hint
+ required: false
+ type: string
+ x-example: eyJhbGciOiJSUzI1NiIsImtpZCI6IjdlOGFkZmM
+##### login_hint
+ - in: query
+ name: login_hint
+ description: >-
+ login_hint_token should
+ be used by the SP as a login hint with the particular MNO, so the
+ MNO recognises the SP that is trying to get a response.acr used during authentication
+ is returned as acr claim value. This parameter is optional, however,
+ when it is present the Authentication endpoint should satisfy one for the end-user's authentication. The recommended values are the LOAs as
+ specified in ISO/IEC 29115
+ Clause 6 – 1, 2, 3, 4 – representing the LOAs of LOW, MEDIUM, HIGH and VERY HIGH.authorization_code.
+ x-example: authorization_code
+##### code
+ - in: formData
+ name: code
+ type: string
+ required: true
+ description: >-
+ correlation_id submitted in the initial
+ authorize request. The correlation_id tracks the transaction
+ correlation across the Mobile Connect components (Discovery, Mobile
+ Connect). The value for this parameter is generated only by the SP and it
+ must be locally unique.client_id:client_secretBearerclient_id field obtained from the Discovery response
+ which is used as the unique client identifier of the SPredirect_uri is defined during application
+ registration.code to
+ indicate the Authorisation Code Flow.mc_di_r2_v2.3) and Mobile Connect Profile v2.0 (mc_v2.0).page: The UI SHOULD be consistent with a full page view of the User-Agent.pop-up: Use a pop-up window. (The popup window SHOULD be 450px X 500px) touch: Display a UI consistent with a “touch” based interface.wap: The UI SHOULD be consistent with a “feature-phone” device displaynone: MUST NOT display any UI for reauthentication or consent to the user. If the user is not authenticated already, or authentication or consent is needed to process the Authorisation Request, a login_required error is returned. This can be used as a mechanism to check existing authentication or consent.no_seam: prompt the end-user if the authentication session is not valid. Caters for the 3G/4Ghot-spots, tethered phone etc. scenariosauth_time claim valueprompt=none. If the ID Token is still valid and the
+ end-user is logged in then the server returns a positive response,
+ otherwise server SHOULD return a login_error response. For
+ the ID Token, the server does not need to be listed as audience,
+ when included in the id_token_hint
+ required: false
+ type: string
+ x-example: eyJhbGciOiJSUzI1NiIsImtpZCI6IjdlOGFkZmM
+##### login_hint
+ - in: query
+ name: login_hint
+ description: >-
+ login_hint_token should
+ be used by the SP as a login hint with the particular MNO, so the
+ MNO recognises the SP that is trying to get a response.acr used during authentication
+ is returned as acr claim value. This parameter is optional, however,
+ when it is present the Authentication endpoint should satisfy one for the end-user's authentication. The recommended values are the LOAs as
+ specified in ISO/IEC 29115
+ Clause 6 – 1, 2, 3, 4 – representing the LOAs of LOW, MEDIUM, HIGH and VERY HIGH.authorization_code.
+ x-example: authorization_code
+##### code
+ - in: formData
+ name: code
+ type: string
+ required: true
+ description: >-
+ correlation_id submitted in the initial
+ authorize request. The correlation_id tracks the transaction
+ correlation across the Mobile Connect components (Discovery, Mobile
+ Connect). The value for this parameter is generated only by the SP and it
+ must be locally unique.client_id:client_secretBearer.client_id field obtained from the Discovery response
+ which is used as the unique client identifier of the SPredirect_uri is defined during application
+ registration.redirect_uri is defined during application
+ registration.
+ {
+ "premiuminfo":{
+ "address_hash":{
+ "value":"5a182f28e16bb73cee76e04015736f5c2f681a2ce1f08bafc6a40167b3a344aa"
+ },
+ "name_hash":{
+ "value":"bb7ff9e6715bf5f87a4adc3620ad2bb194a59ca838c418c033b9c3d55fbcfbce"
+ }
+ }
+ }
+
+
+ mc_di_r2_v2.3.
+ x-example: mc_di_r2_v2.3
+##### state
+ - in: query
+ name: state
+ description: >-
+ page: The UI SHOULD be consistent with a full page view of the User-Agent.pop-up: Use a pop-up window. (The popup window SHOULD be 450px X 500px) touch: Display a UI consistent with a “touch” based interface.wap: The UI SHOULD be consistent with a “feature-phone” device displaynone: MUST NOT display any UI for reauthentication or consent to the user. If the user is not authenticated already, or authentication or consent is needed to process the Authorisation Request, a login_required error is returned. This can be used as a mechanism to check existing authentication or consent.no_seam: prompt the end-user if the authentication session is not valid. Caters for the 3G/4Ghot-spots, tethered phone etc. scenariosauth_time claim valueprompt=none. If the ID Token is still valid and the
+ end-user is logged in then the server returns a positive response,
+ otherwise SHOULD return a login_error response. For
+ the ID Token, the server does not need to be listed as audience,
+ when included in the id_token_hintlogin_hint_token should
+ be used by the SP as a login hint with the particular MNO, so the
+ MNO recognises the SP that is trying to get a response.acr used during authentication
+ is returned as acr claim value. This parameter is optional, however,
+ when it is present the Authentication endpoint should satisfy one for the
+ end-user's authentication. The recommended values are the LOAs as
+ specified in ISO/IEC 29115
+ Clause 6 – 1, 2, 3, 4 – representing the LOAs of LOW, MEDIUM, HIGH and VERY HIGH.authorization_code.
+ x-example: authorization_code
+##### code
+ - in: formData
+ name: code
+ type: string
+ required: true
+ description: >-
+ correlation_id submitted in the initial
+ authorize request. The correlation_id tracks the transaction
+ correlation across the Mobile Connect components (Discovery, Mobile
+ Connect). The value for this parameter is generated only by the SP and it
+ must be locally unique.client_id:client_secretBearerBearerBearerBearerauthorization_code to indicate that the grant
+ type to use is the Authorisation Code Flow. correlation_id submitted through the authentication
+ request. correlation_id ensures the transaction
+ correlation across Mobile Connect components (Discovery, Mobile
+ Connect Profile requests, IDGW internal components etc.). The value
+ for this parameter is generated only by the SP and it must be locally
+ unique.
Please note that the usage of this parameter is not
+ mandatory. However, if this parameter is present in the request, the
+ IDGW must add this parameter to the response. When the SP sends a
+ request without the correlation_id parameter, it's up to
+ the IDGW whether to include this parameter into the
+ response.
For more information on the correlation ID please see + the Correlation ID section
This + parameter is optional for Mobile Connect DI Profile 2.3, SI Profile + 1.0, Mobile Connect Profile 2.0 and is not supported by the Mobile + Connect Profile 1.0
+ example: 42da5b19-457a-4d30-a5c4-038c62dccbb0 + required: + - grant_type + - code + - redirect_uri +######################################################################################### +# RESPONSE 200 OK +######################################################################################### +######################################################################################### +# RESPONSE 200 OK - TOKENS +######################################################################################### + Response_200_for_Get_Tokens: + type: object + properties: + token_type: + type: string + description: >- +Type of the HTTP authentication scheme. The value for this parameter
+ must be bearer unless another token_type
+ value was agreed between the Service Provider and the ID Gateway.
Token used to provide claims about the authentication of + the end-user and other specific claims, if requested. For the detailed + list of the possible claims to be returned please see Tokens section.
+ +The ID Token is a JSON Web Token (JWT). It is created and returned + by the ID Gateway and is associated with only one authentication session. A + new authentication session for the same end-user will be provided with + a new ID Token
+ example: eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso + access_token: + type: string + description: >- +OAuth 2.0 token used to get access to + protected resources from the PremiumInfo endpoint.
+ example: 7d6e93c2-54a8-4b98-b08f-f047e519d788 + expires_in: + type: string + description: >- +Expiration time of the Access Token in seconds since the response was generated.
+ example: 3600 + correlation_id: + type: string + description: >- +correlation_id submitted through the authentication
+ request.
This parameter is not supported by the Mobile Connect Profile 1.1
+ example: 42da5b19-457a-4d30-a5c4-038c62dccbb0 + required: + - access_token + - token_type + - expires_in + - id_token +######################################################################################### +# RESPONSE 200 OK - TOKENS WITH PREMIUMINFO REFERENCE +######################################################################################### + Response_200_for_Get_Token_Premiuminfo: + type: object + properties: + access_token: + type: string + description: >- +OAUth 2.0 access_token used to get the PremiumInfo object
+ from the PremiumInfo endpoint (or other specific resource endpoint)
+ and can be reused for accessing the protected resources, if required.
Value MUST be bearer unless another
+ token_type value was agreed between the Service Provider and the
+ ID Gateway.
Expiration time of the Access Token in seconds since the response was + generated
+ example: 600 + id_token: + type: string + description: >- +This is an additional token used to provide the ID token claims. The + ID token is a JSON Web Token (JWT) sent by the IDGW to the SP's + Server.For more on how to handle the ID Token and the available claims + please refer to Tokens page.
+ example: eyJhbGciOiJSUzI1Ni1QifQ.eyJh5eUxXST01lIjoxNTIyMzI4NTc0LjAsImF6cCI6I + correlation_id: + type: string + description: >- +The correlation_id submitted through the authentication
+ request. correlation_id ensures correlation of the
+ transaction across Mobile Connect components.
birthdate is present.
+ example: Y
+ is_lost_stolen:
+ type: string
+ enum:
+ - false
+ - true
+ description: Has the end-user account been marked as lost or stolen
+ example: false
+ billing_segment:
+ type: string
+ enum:
+ - PAYM
+ - PAYG
+ - Business
+ description: End-users billing type
+ example: PAYM
+ account_state:
+ type: string
+ enum:
+ - active
+ - inactive
+ description: End-users account status
+ example: active
+ required:
+ - sub
+ - given_name
+ - given_name_match
+ - family_name
+ - family_name_match
+ - houseno_or_housename
+ - houseno_or_housename_match
+ - postal_code
+ - postal_code_match
+ - town
+ - town_match
+ - country
+ - country_match
+#########################################################################################
+# RESPONSE 200 OK - KYC PLAIN TEXT CONCAT
+#########################################################################################
+ Response_200_KYC_Match_Concat:
+ type: object
+ properties:
+ sub:
+ type: string
+ description: >-
+ Subject identifier, a globally unique identifier (see PCR) of the
+ end-user generated by the operator.
+ example: 22735ae2-9b1b-4edb-bed0-7b41de9e129e
+ name:
+ type: string
+ description: Concatenated given_name and family_name.
+ example: Case
+ name_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ address:
+ type: string
+ description: Concatenated houseno_or_housename_match, postal_code, town and country.
+ example: 25 Walbrook, London, EC4N 8AF, UK
+ address_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ birthdate:
+ type: string
+ description: Date of birth of the end-user
+ example: 1948-03-17T00:00:00.000Z
+ birthdate_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result. Required if birthdate is present.
+ example: Y
+ is_lost_stolen:
+ type: string
+ enum:
+ - false
+ - true
+ description: Has the end-user account been marked as lost or stolen
+ example: false
+ billing_segment:
+ type: string
+ enum:
+ - PAYM
+ - PAYG
+ - Business
+ description: End-users billing type
+ example: PAYM
+ account_state:
+ type: string
+ enum:
+ - active
+ - inactive
+ description: End-users account status
+ example: active
+ required:
+ - sub
+ - name
+ - name_match
+ - address
+ - address_match
+#########################################################################################
+# RESPONSE 200 OK - KYC HASHED SPLIT
+#########################################################################################
+ Response_200_KYC_Hashed_Split:
+ type: object
+ properties:
+ sub:
+ type: string
+ description: >-
+ Subject identifier, a globally unique identifier (see PCR) of the
+ end-user generated by the operator.
+ example: 22735ae2-9b1b-4edb-bed0-7b41de9e129e
+ given_name_hash:
+ type: string
+ description: The hashed given name(s) or first name(s) of the end-user
+ example: 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12
+ given_name_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ family_name_hash:
+ type: string
+ description: Hashed family name(s), surname(s) or last name(s) of the end-user'
+ example: 3fd4e1c67a2d28fced849ee1bb76e7391b93eb13
+ family_name_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ houseno_or_housename_hash:
+ type: string
+ description: End-users house number or name of house
+ example: g12f2c7fd25e1b3afad3e69a0bd17d9b100db4b2
+ houseno_or_housename_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ postal_code_hash:
+ type: string
+ description: End-user's postal or zip code
+ example: b784e1c67a2d28fced849ee1bb76e739112bc43
+ postal_code_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ town_hash:
+ type: string
+ description: End-user's town or city
+ example: 3e85a0bd17d9b100db4b1feff2c7fd25e1b3afad
+ town_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ country_hash:
+ type: string
+ description: End-user's country
+ example: b4b27fd25e1b3afad3e69a0bd17d9bg12f2c100d
+ country_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ birthdate_hash:
+ type: string
+ description: Date of birth of the end-user
+ example: 2c7fd25e1b3afad0db4b33e85a0bde9fd17d9b10
+ birthdate_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result. Required if birthdate_hash is present.
+ example: Y
+ is_lost_stolen:
+ type: string
+ enum:
+ - false
+ - true
+ description: Has the end-user account been marked as lost or stolen
+ example: false
+ billing_segment:
+ type: string
+ enum:
+ - PAYM
+ - PAYG
+ - Business
+ description: End-users billing type
+ example: PAYM
+ account_state:
+ type: string
+ enum:
+ - active
+ - inactive
+ description: End-users account status
+ example: active
+ required:
+ - sub
+ - given_name_hash
+ - given_name_match
+ - family_name_hash
+ - family_name_match
+ - houseno_or_housename_hash
+ - houseno_or_housename_match
+ - postal_code_hash
+ - postal_code_match
+ - town_hash
+ - town_match
+ - country_hash
+ - country_match
+#########################################################################################
+# RESPONSE 200 OK - KYC HASHED CONCAT
+#########################################################################################
+ Response_200_KYC_Hashed_Concat:
+ type: object
+ properties:
+ sub:
+ type: string
+ description: >-
+ Subject identifier, a globally unique identifier (see PCR) of the
+ end-user generated by the operator.
+ example: 22735ae2-9b1b-4edb-bed0-7b41de9e129e
+ name_hash:
+ type: string
+ description: Hashed concatenation of given_name and family_nme
+ example: de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3
+ name_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ address_hash:
+ type: string
+ description: Concatenated houseno_or_housename_match, postal_code, town and country.
+ example: feff2c7fd25e1b3afad3e85a0bd17d9b100db4b1
+ address_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result
+ example: Y
+ birthdate_hash:
+ type: string
+ description: Date of birth of the end-user
+ example: 2c7fd25e1b3afad0db4b33e85a0bde9fd17d9b10
+ birthdate_match:
+ type: string
+ enum:
+ - Y
+ - N-NA
+ - N-AV
+ - Y-AD
+ description: Match result. Required if birthdate_hash is present.
+ example: Y
+ is_lost_stolen:
+ type: string
+ enum:
+ - false
+ - true
+ description: Has the end-user account been marked as lost or stolen
+ example: false
+ billing_segment:
+ type: string
+ enum:
+ - PAYM
+ - PAYG
+ - Business
+ description: End-users billing type
+ example: PAYM
+ account_state:
+ type: string
+ enum:
+ - active
+ - inactive
+ description: End-users account status
+ example: active
+ required:
+ - sub
+ - name_hash
+ - name_match
+ - address_hash
+ - address_match
+#########################################################################################
+# RESPONSE 400 BAD REQUEST
+#########################################################################################
+ Response_400_Authorize:
+ type: object
+ properties:
+ error:
+ type: string
+ description: >-
+ Error code. This will be invalid_request.
Error description. This will be redirect_uri is invalid.