...
border | true |
---|
Column | ||||
---|---|---|---|---|
| ||||
Table of contents
|
...
width | 70% |
---|
Thank you for subscribing to Freja eID services.
Freja eID is an electronic identification (eID) solution for citizens and organisations which can be used for identity assertion, authentication and signing. The essential part of Freja eID service is a smartphone application used for login and signing to all the services that are connected to the user´s eID. The second part is a web portal – My Pages – where the user can control how their eID is to be used and has a full record of user history.
In terms of relying parties, Freja eID offers great flexibility in terms of addressing end users. For example, the identity assurance level of end users registered with Freja eID can vary. If the user has followed an entry-level registration flow their identity will be assured to level 2 within the scheme, also known as Freja eID Basic. At this level a user will have confirmed an email address and/or a mobile phone number, perfectly enough to allow, for example, login authentication in situations where an absolute identity is not of significance for the relying party - knowing that the end user accessing a relying party's service is the same one that accessed the service a week ago without the hassle of teaching the end user an additional password is perfectly enough for many web-based services.
However, if the end user opted for an extended registration process their identity will be assured to level 3 within the scheme, also known as Freja eID+. The extended registration process involves, amongst other controls, vetting physical ID documents of the end user and face enrolment with Freja eID. Freja eID+ users can be referred to through their social security number (SSN). In Sweden, this would equate to having established a "personnummer" for the end user. Also, Freja eID+ users can be involved in interactions with web parties that involve login, but also legally binding signatures and identity assertion. If you want to find out more about identity assertion levels, please have a look at the Tillitsnivåer för elektronisk legitimation published by the Swedish e-Identification board.
This document contains instructions for enabling relying party (RP) applications to use services offered by Freja eID. It is of a technical nature - if you are not a software architect or developer, it is probably the wrong document to read. Freja eID offers three services to RPs: Identity assertion service, Authentication service and Signing service. Our recommendation is to read the sections of interest to you in their entirety at least once. On later occasions, use the links above to quickly navigate to the section of interest.
Document versions
Version | Date | Comment |
---|---|---|
1.0 | 2017-04-26 | This document is a preliminary version. The content of this document is still under review and subject to change. |
2.0 | 2017-05-29 | Included authentication services. Changed examples to use signing certificate under Freja eID TEST root. |
2.1 | 2017-06-23 | Adjusted error codes to comply with conventions within other services. |
2.2 | 2017-06-30 | Adjusted error codes for validation errors. Instead of generic error 1000 and list of specific errors, specific error is returned directly. |
2.3 | 2017-08-03 | Opaque data must be max 128 characters long. Adjusted identity assertion error codes. |
2.4 | 2017-08-10 | Changed the URL for posting the response for identity assertion. |
2.5 | 2017-09-13 | Changed the JWS header value from x5c to x5t. |
2.6 | Added support for requesting additional user attributes for authentication. | |
3.0 | Changed the endpoint URLs for all authentication service methods. Adjusted error codes in Auhentication service. Included Signature services. |
Certificates
There are several examples where the data has been signed using RSA keys and certificates below. In all cases, the private key corresponding to the following certificate chain has been used:
Certificate | Details | ||
---|---|---|---|
End-entity (for signing key) | Subject: CN=Documentation and Demo, OU=Test, O=Verisec Freja eID AB, OID.2.5.4.97=559110-4806, L=Stockholm, C=SE
Base64 encoding:
| ||
Intermediate | Subject: CN=RSA TEST Issuing CA, OU=Test, O=Verisec Freja eID AB, OID.2.5.4.97=559 110-4806, L=Stockholm, C=SE | ||
Root | Subject: CN=RSA Test Root CA, OU=Freja eID, O=Verisec AB, C=SE |
All JWS headers are, therefore, identical and equal to the following:
Field | Value | ||
---|---|---|---|
Header | "alg":"RS256" | ||
Base64 encoding of header |
|
Identity assertion service
Freja eID Identity assertion service is used by entities that wish to perform identity switching, or simply wish to receive confirmation of strong authentication for an individual. The following diagram illustrates the flow of control for this service.
In step one, the relying party invokes a custom URL on a device where Freja eID mobile app is installed. The URL passes RP identity, protocol version and opaque data as parameters. In step two, Freja eID mobile app sends these parameters to the back end for validation - if something is wrong, an error is immediately displayed in the Freja eID app.
As far as Step 3 is concerned, it is worth noting that a prerequisite for the identity assertion service is that the user has been vetted to Freja eID+. In order to make the identity assertion service as user-friendly as possible, the process can be initiated (Step 1 in the diagram above), regardless of whether the user is at Freja eID Basic or Freja eID+ level. However, the completion is only possible once the user has vetted their identity to Freja eID+. Thereby, the following two scenarios can occur:
- The identity assertion service is initiated through either of the methods above and the user has Freja eID Basic. A transaction is queued in the Freja eID server side, but cannot be approved by the end user until the user raises the assurance of their identity to Freja eID+.
- The identity assertion service is initiated through either of the methods above and the user already has Freja eID+. The transaction can immediately be displayed for the user. Following the user's approval through either a PIN or biometric method (for example, TouchID), the transaction is completed on the server side.
Once the user's approval is received and processed, Step 3 can commence and a response is sent back to the relying party that requested identity assertion. The posted data will contain the country and SSN of the individual associated with the Freja eID app residing on the mobile device where the process of identity assertion was initiated.
Before you begin
There are several technical requirements that must be in place before the implementation can start. Please complete the checklist below before proceeding:
- Obtain a symmetric key and a Relying party ID from Verisec for accessing the test environment. The RP ID is a unique identifier of the organisation which uses Freja eID.
- Obtain the JSON Web Signature (JWS) certificate of Freja eID test environment and import it into your system.
- Provide Freja eID with an HTTPS endpoint for receiving identity assertions in your test environment (e.g. https://relyingparty.com:8443/identityAssertionServer) and your endpoint certificate chain.
Production checklist
- Sign a contract providing your organisation access to the Identity assertion service
- Obtain a symmetric key and a Relying party ID from Verisec for accessing the production environment. The RP ID is a unique identifier of the organisation which uses Freja eID.
- Obtain the JSON Web Signature (JWS) certificate of Freja eID and import it into your system.
- Provide Freja eID with an HTTPS endpoint for receiving identity assertions (e.g. https://relyingparty.com:8443/identityAssertionServer) and your endpoint certificate chain.
Identify method
This method is used for obtaining an assertion of end user's identity from the Freja eID service. A user must be vetted to level 3 (Freja eID+) before steps two and three in the diagram can be completed. In other words, while a relying party can invoke the Identify method regardless of the identity assertion level of the end user, the end user must be vetted to level 3 before they will be allowed to confirm releasing information about their identity to the relying party. It is, therefore, worthwhile pointing out that the flow above is not synchronous - step 1 can precede steps 2 and 3 by an arbitrary amount of time (controlled by the relying party, see the details of the method parameters below), giving an opportunity to the end user to complete the extended registration process. During this period, the user will be aware of a pending identity assertion action, but will not be able to complete it.
The method can be invoked from a browser or an application on the mobile phone on which the Freja eID app is installed. The invocation is actually performed through opening a custom URL with a scheme registered by the Freja eID app. Preconditions for a successful operation are, therefore, that the Freja eID is installed on the device before the custom URL is invoked, and that the mobile device is online as the Freja eID must contact the Freja eID infrastructure in order to fulfil the request. The custom URL should be constructed as follows:
Custom URL scheme for invoking the Identify method |
---|
frejaeid://identify?iaRequestData=abcdefgh |
where the content of the iaRequestData parameter is described in the table below.
Input Parameter Name | Value | ||||
---|---|---|---|---|---|
iaRequestData | JWS in compact serialised form as following: BASE64URL(UTF8(JWS Protected Header)) || ’.’ || BASE64URL(JWS Payload) || ’.’ || BASE64URL(JWS HMAC)
JWS Protected Header
kid: string, mandatory. The key id used to secure the message. The key (and its respective key id) are determined between Freja eID service and the identity assertion relying party when signing up for the service.
JWS Payload
iarp: string, mandatory. Identity assertion relying party reference agreed at the time of enrolling the relying party for the service. |
Example request:
Field | Value | ||
---|---|---|---|
Header | "alg":"HS256" | ||
Payload | "exp":1493806530000 | ||
Key value (hexadecimal format) | 000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f | ||
Final JWS (compact format, line broken for clarity only) |
|
Possible errors when initiating the request
The error codes that may be displayed by the Freja eID mobile application upon initiating an identity assertion request have the following meanings:
Return code | Explanation |
---|---|
4000 | Decoding of JWS encoded iaRequestData failed. For example, it could not be separated into header, payload and signature parts. |
4001 | Cannot perform JWS validation.Reason could be unsupported algorithm. |
4002 | Validation of JWS digital signature failed. Reasons could include modifications of the JWS document after signing or a wrongly constructed signature. |
4003 | Invalid signer. For example, unknown keyid. |
4004 | Decoding of payload failed. |
4005 | Invalid expiry time. |
4006 | Unknown identity assertion relying party. |
4007 | Unknown protocol. |
4008 | Identity assertion relying party mismatch with specified keyid. |
4009 | Relying party not subscribed to identity assertion. |
4010 | Request already completed. |
4011 | The user has disabled the relying party service. |
Posting the identity data
The relying party is responsible for operating a web service where Freja eID will post responses containing the requested identity information once the end user approves that. The exact URL is determined between the relying party and Freja eID upon onboarding the relying party to the service (see 3.0 Draft Freja eID Relying Party Developers' Documentation above). A response to the relying party is only posted once a user confirms the release of their social security number to the relying party that initiated the request. Please observe that no response will ever be posted if:
- the request initiated through the customer URL above was invalid, resulting in an error displayed within the Freja eID app;
- the user has not completed the extended registration process to vet their identity to level 3 before, or within the stipulated time limit, provided by the relying party when the request was initiated;
- the user has ignored confirming the action or has actively cancelled the release of their SSN to the initiating relying party.
It is the responsibility of the relying party to clean up any outstanding data and transactions on its end, pertaining to initiated identity assertion requests which have not been responded to within the time limits of the "exp" parameter (see the parameters above).
Posting the response |
---|
https://<determined by relying party>/verisec/vetting-result |
The call is made using the HTTP POST method with the following JSON structure in the body:
Response parameter name | Value | ||||
---|---|---|---|---|---|
iaResponseData | JWS in compact serialised form as following: BASE64URL(UTF8(JWS Protected Header)) || ’.’ || BASE64URL(JWS Payload) || ’.’ || BASE64URL(JWS Signature)
JWS Protected Header
x5t: mandatory, Base64URL encoding of the certificate's SHA-1 digest.
JWS Payload
ref: string, mandatory. Unique service transaction reference that can be used for further investigation related to the call. |
Example data:
Field | Value | ||
---|---|---|---|
Certificate info | See above. | ||
Header | See above. | ||
Payload | "ref":"1234.5678.9012.3456" | ||
Final JWS (compact format, line broken for clarity only) | (header omitted for brevity)
|
General information about Freja eID RESTful APIs
Authentication and Signing services are exposed through a RESTful API. This section presents information common to both services. Firstly, the following applies to HTTP response codes.
HTTP response code | Interpretation |
---|---|
200 OK | Success, additional information is available in the body. |
204 No Content | Success, no additional information is available in the body. |
400 Bad Request | The request is malformed. For example, the body cannot be parsed. |
404 Not Found | Requested resource does not exist. |
410 Gone | Requested resource is no longer available. For example, an obsolete API version. |
422 Unprocessable Entity | Validation or processing errors. Additional information is available in the body. If the input is corrected, the request can be resubmitted. |
500 Internalservererror | The request, although probably OK, could not be processed due to an internal server error. Repeating the request is not recommended, the application should return a sensible error message to the end user. |
General information on error handling
Where errors need to be conveyed (for example, in the case of HTTP 422 code for a RESTful API), the following structure is returned in the body. Note that the code and error message are always present in a case of error.
Code Block |
---|
{
"code": "Integer with error code value",
"message": "Error description"
} |
Authentication services
...
In step one, a relying party invokes the Freja eID authentication service submitting a user identifier and, optionally, a Freja eID assurance qualifier (Freja eID or Freja eID+), and requests that the user approves authentication to a service operated by the relying party. Should the relying party service be residing on the same mobile device (i.e. accessed through a mobile browser or mobile app), the service can activate the Freja eID mobile application directly. Otherwise, the service will need to instruct the end user to start the Freja eID mobile application on one of the enabled devices. In step two, the Freja eID mobile application and authentication service work on presenting the login request to the end user and solicit approval for it. Finally, in step three, the relying party polls for the status of the authentication request until it receives a positive result or an error allowing it to proceed with allow, or reject end user access to its service, respectively.
Before you begin
There are several technical requirements that must be in place before the implementation can start. Please complete the checklist below before proceeding:
- Obtain an SSL client certificate providing you access to the Freja eID test environment.
- Import Freja eID Test root certificate as trusted into the trust store of your application.
- Using Freja eID mobile application, register one or more users with the Freja eID Test infrastructure.
Production checklist
In order to use Freja eID in a production environment, you must fulfil the following:
- Sign a contract allowing your organisation to access the production Freja eID Authentication service.
- Provide Freja eID with a logo suitable to represent your organisation in the mobile application, as well as a display name. The logo must be delivered in one of the vector file formats: .ai, .eps or editable .pdf.
- Obtain an SSL client certificate providing you access to the Freja eID production environment.
- Import Freja eID Production root certificate as trusted into the trust store of your application.
Initiate authentication method
This method is used by a relying party to initiate an authentication request. The method is intended for authentication in online contexts where the access to the relying party's service or application is initiated by the end user. The authentications are therefore short-lived — from the point of initiation, the user has a maximum of two minutes to confirm the authentication through a Freja eID mobile application. Only one active authentication may exist for any given end user at any given time. An attempt to concurrently start a second authentication, by the same or a different relying party, will cancel both initiated authentication requests.
The method is called using HTTP POST through the URLs below:
System | Method endpoint |
---|---|
Test | https://services.test.frejaeid.com/authentication/1.0/initAuthentication |
Production | https://services.prod.frejaeid.com/authentication/1.0/initAuthentication |
The parameter of the method is a Base64 encoded JSON payload according to the following:
Parameter name | Value | |||||||
---|---|---|---|---|---|---|---|---|
initAuthRequest |
userInfoType: string, mandatory. Describes the type of user information supplied to identify the end user. Currently one of: TFN (end user's telephone number), EMAIL (end user's email), SSN (end user's social security number), CUST (a custom identifier). userInfo: mandatory. If userInfoType is EMAIL or TFN, interpreted as a string value of the email or telephone number of the end user, respectively. If userInfoType is SSN, then it must be a Base64 encoding of the ssnuserinfo JSON structure described below. If userInfoType is CUST, then see custuserinfo below. askForBasicUserInfo: boolean value, optional, by default set to false. When retrieving results, if this parameter is set to true, additional information about the user (name and surname) can be returned. In that case, userInfoType must be SSN. restrict: base64 string, optional. A value that restricts the login action only to the Freja eID mobile application started with the same parameter. This can be used in situations where the relying party service is accessed through a browser or app on the same device as the Freja eID app. By passing the same restrict value to the initAuthRequest as to the start of the mobile application, the relying party application can target the usage of the Freja eID on the same device. If present, max 64 characters (post Base64 encoding).
minRegistrationLevel: string, optional. Minimum required registration level of a user in order to approve/decline authentication. If not present, default level will be BASIC.
| |||||||
ssnuserinfo |
country: string, mandatory. Contains the ISO-3166 two-alphanumeric country code of the country where the SSN is issued. In the current version of Freja eID, must be equal to "SE". | |||||||
custuserinfo |
|
Possible errors returned by the method are the following:
Return code | Explanation |
---|---|
1001 | Invalid or missing userInfoType. |
1002 | Invalid or missing userInfo. |
1003 | Invalid restrict. |
1004 | You are not allowed to call this method. |
1005 | The user has not enabled your service. |
1007 | Invalid min registration level. |
2000 | Authentication request failed. Previous authentication request was rejected due to security reasons. |
2001 | The value of userInfoType must be set to SSN when asking for additional user info. |
If HTTP 200 is returned from the method, the following return value will be present in the body of the response:
JSON Response Value in body | ||
---|---|---|
authRef: string, mandatory. A reference unique to the transaction that can be used to query the result of a specific transaction (see 3.0 Draft Freja eID Relying Party Developers' Documentation below). |
Initiating Freja eID app in authentication mode
The method can be invoked from a browser or an application on the mobile phone on which the Freja eID app is installed. The invocation is actually performed through opening a custom URL with a scheme registered by the Freja eID app. Preconditions for a successful operation are, therefore, that the Freja eID is installed on the device the custom URL is invoked, and that the mobile device is online, as the Freja eID must contact the Freja eID infrastructure in order to fulfil the request. The custom URL should be constructed as follows:
Custom URL scheme for invoking the Identify method |
---|
frejaeid://authenticate?restrict=abcdefgh |
Methods for retrieving authentication results
There are two methods that can be used for fetching authentication results: one that returns a single result for a specified authentication reference (authRef returned from a call to 3.0 Draft Freja eID Relying Party Developers' Documentation), and one that returns multiple authentication results. The latter is the preferred way of fetching results in situations where a relying party has many concurrent authentications in progress, as it reduces the number of polling requests.
Get one authentication result method
The method is called using HTTP POST through the URLs below:
System | Method endpoint |
---|---|
Test | https://services.test.frejaeid.com/authentication/1.0/getOneResult |
Production | https://services.prod.frejaeid.com/authentication/1.0/getOneResult |
The parameter of the method is a Base64 encoded JSON payload according to the following:
Parameter name | Value | |||
---|---|---|---|---|
getOneAuthResultRequest |
authRef: string, mandatory. The value must be equal to an authentication reference previously returned from a call to the 3.0 Draft Freja eID Relying Party Developers' Documentation. As mentioned above, authentications are short-lived and, once initiated by a relying party, must be confirmed by an end user within two minutes. Consequently, fetching the result of an authentication for a given authentication reference is only possible within 10 minutes of the call to 3.0 Draft Freja eID Relying Party Developers' Documentation that returned the said reference. |
Possible errors returned by the method are the following:
Return code | Explanation |
---|---|
1100 | Invalid reference (for example, nonexistent or expired). |
If HTTP 200 is returned from the method, the following return value will be present in the body of the response:
...
...
Code Block |
---|
{
"authRef":"Authentication reference",
"status":"Authentication status",
"basicUserInfo":{"name":"user's name","surname":"user's surname"},
"details":"JWS signed data, see below"
} |
authRef: string, mandatory. The authentication reference of the authentication.
status: string, mandatory. One of: STARTED (the transaction has been started but not yet delivered to Freja eID application associated with the end user), DELIVERED_TO_MOBILE (the Freja eID app has downloaded the transaction), CANCELLED (the end user declined the authentication request), EXPIRED (the authentication request was not approved by the end user within the authentication validity limit of two minutes), APPROVED (the authentication was successful) or REJECTED (e.g. if you try to run more than one authentication transaction for the same user at the same time).
basicUserInfo: JSON object (see below), optional. Provides additional attributes about user if the askForBasicUserInfo in related initAuthRequest was set to true and status is APPROVED.
details: JWS signed object (see below), optional. Provides details and evidence of the authentication if status was equal to APPROVED.
...
...
Section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
authRef: See authRef above. basicUserInfo | { "name" : "User's name" , "surname" : "User's surname" }
Example data for APPROVED response, JSON response body:
Get authentication results methodThe method allows a relying party to fetch the results of multiple outstanding authentications. It is our recommendation that relying parties generally use the aggregate method, as it is more efficient and reduces network traffic. This is the default behaviour of client libraries supplied by Freja eID. The method is called using HTTP POST through the URLs below:
The parameter of the method is a Base64 encoded JSON payload according to the following:
Possible errors returned by the method are the following:
If HTTP 200 is returned from the method, the following return value will be present in the body of the response:
Anchor | topOfThePage | topOfThePage | Signature servicesFreja eID Signature services allow relying parties to securely deliver messages to a user, as well as to prompt Freja eID end users to digitally sign data and documents. The end user will have previously downloaded the Freja eID mobile application on one or more iOS or Android devices they possess, and registered with Freja eID, allowing them to be referred to by relying parties through the use of one or more email addresses. Signature services are available to both Basic and end users that have upgraded to Freja eID+. Signatures created by the end users are PKI-based and therefore non-repudiable. The signature flow is practically identical to that of authentication depicted in the section on 3.0 Draft Freja eID Relying Party Developers' Documentation. The key difference is that whereas a user can only have one authentication transaction active at any given time and the duration of authentication transactions is limited to two minutes, multiple signatures can be pending for a user's approval and each individual signature transaction can be open for up to 30 days (i.e. from the initiation by a relying party an end user may have up to 30 days to perform the signing). This allows for flexible signing solutions to be built on top of Freja eID where users can be prompted to sign even outside a direct online context. Signature typesFreja eID allows for several types of signatures. Simple signature typeThe SIMPLE signature type allows signing of UTF-8 text. Upon completion of the signature by the user, the relying party receives a JWS structure containing the data that was presented to the user, as well as evidence that the Freja eID infrastructure has validated the signature. Extended signature typeThe extended signature type allows signing of UTF-8 text (presented to the user) alongside binary data (not presented to the user). Upon completion of the signature by the user, the relying party receives a JWS structure containing the data that was presented to the user and the supplied binary data, as well as evidence that the Freja eID infrastructure has validated the signature. Advanced signature typeThe advanced signature type allows signing of UTF-8 text (presented to the user), binary data (not presented to the user) or both to be signed in XML or CMS formats. Subject to the type of binary data, the value returned to the relying party will be one of the following:
Before you beginThere are several technical requirements that must be in place before the implementation can start. Please complete the checklist below before proceeding:
Production checklistIn order to use Freja eID in a production environment, you must fulfil the following:
Initiate Sign MethodThis method is used by a relying party to initiate a signing transaction. The method is intended for creating signatures both in online contexts, where the access to the relying party's service or application is initiated by the end user, as well as in offline contexts, where the signature request is initiated by the relying party's service in its own right. Signature transactions, therefore, have configurable longevity — from the point of initiation, the user has between two minutes and 30 days to confirm the signature request. As opposed to authentication requests, multiple signature requests may be active at any given time, from the same or different relying parties. Although in most cases possession and control of the handheld device on which a Freja eID app is installed are sufficient for allowing the user to view transaction content when initiating a transaction, a relying party can also specify whether the content is confidential or not. The confidentiality flag governs whether the user must present the PIN or, if enabled, use one of the biometric authentication alternatives on the handheld device, before being allowed to view the transaction content. The option effectively provides an option to have transactions that are "signed-for (for viewing) with explicit consent (for accepting the content)". The method is called using HTTP POST through the URLs below:
The parameter of the method is a Base64 encoded JSON payload according to the following: Parameter name Value initSignRequest |
userInfoType: string, mandatory. Describes the type of user information supplied to identify the end user. Currently one of: TFN (end user's telephone number), EMAIL (end user's email), SSN (end user's social security number), CUST (a custom identifier). userInfo: mandatory. If userInfoType is EMAIL or TFN, interpreted as a string value of the email or telephone number of the end user, respectively. If userInfoType is SSN, then it must be a Base64 encoding of the ssnuserinfo JSON structure described below. If userInfoType is CUST, then see custuserinfo below.
ssnuserinfo |
country: string, mandatory. Contains the ISO-3166 two-alphanumeric country code of the country where the SSN is issued. In the current version of Freja eID, must be equal to "SE". custuserinfo |
restrict: base64 string, optional. A value that restricts the sign action only to the Freja eID mobile application started with the same parameter. This can be used in situations where the relying party service is accessed through a browser or app on the same device as the Freja eID app. By passing the same restrict value to the initSignRequest as to the start of the mobile application, the relying party application can target the usage of the Freja eID on the same device. If present, max 64 characters (post Base64 encoding).
minRegistrationLevel: string, optional. Minimum required registration level of a user in order to approve/decline signing transaction. If not present, default level will be PLUS. title: string, optional. The title to display in the transaction list if presented to the user on the mobile device. The title will be presented regardless of the confidentiality setting (see below). If not present, a system default text will be presented. pushNotification: JSON structure, optional. The title and the text of the notification sent to the mobile device to alert the user of a signature request. If not present, a system default title and text will be presented. confidential: boolean (true/false), optional. Determines whether the user will be required to enter their Freja eID PIN or, if enabled, use the handheld device's biometric authentication method before being allowed to view the content of the transaction. If not present, defaults to false.
expiry: long, optional. Describes the time until which the relying party is ready to wait for the user to confirm the signature request. Expressed in milliseconds since January 1, 1970, 00:00 UTC. Min value is current time +2 minutes, max value is current time +30 days. If not present, defaults to current time +2 minutes. dataToSignType: string, mandatory. Describes the type of data to be signed. Currently, only SIMPLE_UTF8_TEXT is supported. dataToSign: JSON structure, mandatory. Subject to dataToSignType, all or parts of dataToSign will be displayed to the user prior to soliciting signature approval. JSON structure described below.
signatureType: string, mandatory. The type of signature that is requested. Currently, only SIMPLE is supported.
Possible errors returned by the method are the following:
If HTTP 200 is returned from the method, the following return value will be present in the body of the response:
Methods for retrieving signature resultsThere are two methods that can be used for fetching digital signature results: one that returns a single result for a specified signature reference (signRef returned from a call to 3.0 Draft Freja eID Relying Party Developers' Documentation), and one that returns multiple signature results. The latter is the preferred way of fetching results in situations where a relying party has many concurrent signatures in progress, as it reduces the number of polling requests. Get one signature result methodThe method is called using HTTP POST through the URLs below:
The parameter of the method is a Base64 encoded JSON payload according to the following:
Possible errors returned by the method are the following:
If HTTP 200 is returned from the method, the following return value will be present in the body of the response: | JSON Response Value in body Response body |
signRef: string, mandatory. The signature reference of the signing request. Note | Note: In the current version of Freja eID, OPENED status is not supported. details: A signed object (see below), optional. Provides details and evidence of the signing if status was equal to APPROVED.details | The content of this response element will depend on the sigType requested when the signature was initiated. For a PLUS signature type it will contain a JWS in compact serialised form as following: BASE64URL(UTF8(JWS Protected Header)) || ’.’ || BASE64URL(JWS Payload) || ’.’ || BASE64URL(JWS Signature)
JWS Protected Header
x5t: mandatory, Base64URL encoding of the certificate's SHA-1 digest.
JWS Payload
signRef: See signRef above. Get signature results methodThe method is called using HTTP POST through the URLs below:
The parameter of the method is a Base64 encoded JSON payload according to the following: Parameter name Value getSignResultsRequest |
includePrevious: string, mandatory. Must be equal to ALL or OUTSTANDING_AND_NEW. If equal to ALL, indicates that the complete list of signature requests successfully initiated by the relying party. The time period during which a specific signature reference is available for checking will depend on the longevity of the signature operation (see the expiry parameter in the 3.0 Draft Freja eID Relying Party Developers' Documentation) and is calculated as expiry time plus 3 days. Note | NOTE: In the current implementation of the service must be equal to ALL. Possible errors returned by the method are the following:
If HTTP 200 is returned from the method, the following return value will be present in the body of the response: | JSON Response Value in body Response body |
signatureResults: an array of JSON objects, mandatory. An array of signature result objects (if the signatureRef parameter was passed, the array will always be of length 1). Note | Note: In the current version of Freja eID, OPENED status is not supported. details: A signed object, optional. Provides details and evidence of the authentication if status was equal to APPROVED (see details as described in the 3.0 Draft Freja eID Relying Party Developers' Documentation above). |
|