MobileID

MobileID InApp Mobile integration: Consent Signature

29 views November 12, 2020 November 24, 2020 0

MobileID InApp Mobile integration: Consent Signature

1. Initiate operation on merchant server

The goal of this call is to obtain necessary information to build a proper signing URL.
Note: The nature of the call is out of scope of this document (but this is most commonly HTTP GET).The following information is passed back in response:

  • The name of the oidc_client_id
  • The name of the Signicat signing method
  • redirect_url (on merchant server) where final results should end

The merchant should take care of encrypting this communication in a secure manner.

2. Generate URL

Construct a signing URL as shown below. This is based on information received from the merchant server in the previous step as well as the information already available through the merchant app:

GET <SIGNICAT_AUTHORIZATION_ENDPOINT>?request=<JWT encrypted request object>

The JWT encrypted request object consists of the following :

Header :

  • "enc"="A256CBC-HS512"
  • "typ"="JWE"
  • kid” and “alg” (the values for “kid” and “alg” are specified at <ENV>/oidc/jwks.json)

Payload :

{    
    "login_hint":["externalRef-sampleUser","deviceId-4f5d09bb-4f21-4b4a-8d0d-d1bfc7cf0a9a","metaData-probably Base64 JSON"],
    "scope":"openid profile signicat.sign",
    "signicat_signtext":"I confirm my purchase of broadband subscription Medium500.",
    "acr_values":"urn:signicat:oidc:method:mobileid-inapp-consent-sign",
    "response_type":"code",
    "redirect_uri":" https://labs.signicat.com/redirect",
    "state":"state123",
    "client_id":"sample-mobileid-oidc-client"
}

and additionally the below as well if using PKCE

  • "code_challenge":<CODE CHALLENGE>
  • "code_challenge_method":"S256"

Note: It is possible to include metadata about the MobileID consent signature transaction to be passed back to the merchant application. The above example includes the optional metaData element in the login_hint array.

3. Initiate operation on Signicat’s server

The merchant app executes an HTTP GET request with the URL constructed previously. The normal response would be as below:

{
    "status":"<STATUS>",
    "statusUrl":"<STATUS_URL>",
    "completeUrl":"<COMPLETE_URL>"
}

Note: To be able to perform the subsequent requests, you must keep the cookies you receive and make these available for subsequent requests.

Response error example

{
    "completeUrl": "https://id.signicat.com/...",
    "status": "ERROR",
    "error": {
    "code": "urn:signicat:error:idp:ACCESS_DENIED",
    "message": "Access denied. Wrong credentials."
    },
...
}

If an error occurs during initialization, you will receive a status indicating this, and an error object will be present. Upon error, if you choose to make an HTTP GET request towards the completeUrlyou will get

error=access_denied&
error_description=The Resource Owner did not complete the login. urn:signicat:error:idp:ACCESS_DENIED; Access denied. Wrong credentials.

4. Execute operation toward Encap

If the status was “OK”, you can start the Encap authentication.
This involves the regular startAuthentication() /finishAuthentication() calls towards the Encap Client API.The text for consent signing is returned in response to the startAuthentication call. The app should retrieve this and display it on the device for the user to take an action.

5. Get result of the process — Finalize operation

Using the completeUrl received in step 1, execute an HTTP GET request for the authorization_code.

Carry out the regular OIDC authorization_code sequence of steps to obtain the access_token. See the Finalize operation guide for details.

At the end, make an HTTP GET request to the signature endpoint of the Signicat OIDC server to retrieve the signed JWT.

See the sequence diagram above for an example of what the signature endpoint looks like.

GET <SIGNICAT_SIGNATURE_ENDPOINT> Authorization: Bearer <access_token>

 

Was this helpful?