Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

bordertrue
Column
width30%

 

Table of contents

Table of Contents
stylecircle

 

...

width70%
Info

Copyright Statement

The specifications and information regarding the product in this manual are subject to change without prior notice. All statements, information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind, expressed or implied. Users must take full responsibility for their use of any products.

© Verisec Freja eID 2017. All rights reserved.

 

Introduction

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

VersionDateComment
1.02017-04-26This document is a preliminary version. The content of this document is still under review and subject to change.
2.02017-05-29Included authentication services. Changed examples to use signing certificate under Freja eID TEST root.
2.12017-06-23Adjusted error codes to comply with conventions within other services.
2.22017-06-30Adjusted error codes for validation errors. Instead of generic error 1000 and list of specific errors, specific error is returned directly.
2.32017-08-03Opaque data must be max 128 characters long. Adjusted identity assertion error codes.
2.42017-08-10Changed the URL for posting the response for identity assertion.
2.52017-09-13Changed 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:

CertificateDetails
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
Issuer: CN=RSA TEST Issuing CA, OU=Test, O=Verisec Freja eID AB, OID.2.5.4.97=55 9110-4806, L=Stockholm, C=SE
Serial number: 68aa4aab2d9370641e3507d4219643f631339393
Valid from: Wed May 17 23:19:23 CEST 2017 until: Sun May 17 23:19:23 CEST 2020
Certificate fingerprints:
MD5: E4:C7:7F:5C:6B:17:60:58:F8:BE:06:B0:73:CD:71:CF
SHA1: B0:7F:34:A2:80:2E:1B:CF:64:4B:5D:E5:FD:1F:CE:BC:C2:F7:59:90
SHA256: 8F:3D:CF:75:47:42:36:1A:19:76:86:52:FA:39:80:94:93:A0:C2:B4:5B:
50:7C:06:AC:DC:E5:E0:2A:40:29:5F
Signature algorithm name: SHA256withRSA

 

Base64 encoding:

Code Block
MIIEDTCCAvWgAwIBAgIUaKpKqy2TcGQeNQfUIZZD9jEzk5MwDQYJKoZIhvcNAQELBQAwgYMxCzA
JBgNVBAYTAlNFMRIwEAYDVQQHEwlTdG9ja2hvbG0xFDASBgNVBGETCzU1OTExMC00ODA2MR0wGw
YDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjENMAsGA1UECxMEVGVzdDEcMBoGA1UEAxMTUlNBI
FRFU1QgSXNzdWluZyBDQTAeFw0xNzA1MTcyMTE5MjNaFw0yMDA1MTcyMTE5MjNaMIGGMQswCQYD
VQQGEwJTRTESMBAGA1UEBxMJU3RvY2tob2xtMRQwEgYDVQRhEws1NTkxMTAtNDgwNjEdMBsGA1U
EChMUVmVyaXNlYyBGcmVqYSBlSUQgQUIxDTALBgNVBAsTBFRlc3QxHzAdBgNVBAMTFkRvY3VtZW
50YXRpb24gYW5kIERlbW8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBwTeuSLvrd
Ot8PJ3dfnlDS+tyTV5P35sm/UusrasPya0XUV3ctj8RxD2skLHYMZ10X87EvXBUw4FEKJ9YlwTO
A3UjZ3jXYX9TZlU/r0kZsvf4RBZO8MOje00oRRdx0go4L6SsTcoBQhgimkxBMcCY1aHqGDWMH61
DWxbepa/4Df6xuFegnMQp421mR2FFvRUi74HBCn35oVHZhYviWo7aTyPVFWd2wLN8GiV+jwunHU
Tdq61+f9pqhPJ0CM6VL9oAIl0D0LbDHbMUd4XuV1hB9wM5jKZaGQ3388rWs+9a83/BJjb1Wa5qD
9tICuIl8y/asOcQEuvX7fT7xyPwduvLAgMBAAGjdDByMA4GA1UdDwEB/wQEAwIGwDAMBgNVHRMB
Af8EAjAAMB8GA1UdIwQYMBaAFGp8ig+dcA4c2l8toDwmX4joFb+cMBIGA1UdIAQLMAkwBwYFKgM
EBQowHQYDVR0OBBYEFHgMFxByq68FGuntjoOa+TTXw/7/MA0GCSqGSIb3DQEBCwUAA4IBAQCV9g
0ZuHBWOIdqiLDss/kTr0Obaeap4DEF5uuuxqo2LKn0k1qGHh66uLdxS0i1nWyLZjphPi5l8CxxM
uhw0VZ90u4cguTYsUXy/s1dp12e48m7bVOz/SnghU8ag+2pAO1esSn3LJ0nOMlKe32IMuGLUXPR
ELG151DEam/3yWKeCtEkthPisDLUKHKoc9v6EQEo+IVkGluSWPaIpvdbJpISzW3c0m9Qzu+GqWj
A1ac/BzdHql0UyTIoXB6u2VVbuIAkTLVLeFWlnL6dOD4XoChN9LStqYKn4iovO+DA+AtQt8Q+4B
/8hQnMyNby0Zyn5BJw4dqDWCju5PIFct8IvYuu
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
Issuer: CN=RSA Test Root CA, OU=Freja eID, O=Verisec AB, C=SE
Serial number: 7713823344a16064911fab8744c5e3f5b2a4815e
Valid from: Wed May 17 16:42:52 CEST 2017 until: Mon May 17 16:42:52 CEST 2027
Certificate fingerprints:
MD5: 82:D4:0F:A8:D5:10:A1:7D:B8:17:C3:11:5C:58:28:B9
SHA1: 50:B8:52:25:AA:72:8A:83:DB:76:60:85:CE:3B:C7:25:1F:9B:FD:E3
SHA256: 50:7D:1D:B0:91:76:02:0F:81:AF:06:C4:6D:CC:E5:65:E1:E4:39:B4:8E:
C3:3D:58:4D:DC:6D:4B:CF:5C:74:E2
Signature algorithm name: SHA256withRSA

Root

Subject: CN=RSA Test Root CA, OU=Freja eID, O=Verisec AB, C=SE
Issuer: CN=RSA Test Root CA, OU=Freja eID, O=Verisec AB, C=SE
Serial number: 3c1e2b52a145886ea0ebb6be70b0810ae4e4c464
Valid from: Wed May 10 16:26:00 CEST 2017 until: Fri May 10 16:26:00 CEST 2047
Certificate fingerprints:
MD5: 3E:93:03:ED:5B:EB:A2:E4:CD:73:EA:5A:7D:E7:01:39
SHA1: 59:F6:AB:50:1C:A4:4B:D6:D2:26:F7:44:77:11:C5:AF:D7:DA:A6:2E
SHA256: 8D:74:59:FD:04:60:24:2C:F0:3E:76:D5:F0:42:7E:A9:FE:33:DB:67:89:
D5:06:30:9A:AC:2C:97:DA:A6:E8:60
Signature algorithm name: SHA256withRSA

All JWS headers are, therefore, identical and equal to the following:

FieldValue
Header

"alg":"RS256"
"x5t":"sH80ooAuG89kS13l_R_OvML3WZA"

 

Base64 encoding

of header

Code Block
eyJhbGciOiJSUzI1NiIsIng1dCI6InNIODBvb0F1Rzg5a1MxM2xfUl9Pdk1MM1daQSJ9

 

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.

Image Removed

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

Code Block
{
  "kid": "key id",
  "alg": "algorithm used to secure the JWS"
}

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.
alg: mandatory, the value must be HS256.

 

JWS Payload

Code Block
{ 
   "iarp":"Identity assertion relying party reference",
   "exp":"Expiry time for the request",
   "proto":"The response protocol",
   "opaque":"Relying party correlation data"
}

iarp: string, mandatory. Identity assertion relying party reference agreed at the time of enrolling the relying party for the service.
exp: long, mandatory. Describes the time until which the identity assertion relying party is ready to wait for the response. Expressed in milliseconds since January 1, 1970, 00:00 UTC. Min value is current time +5 minutes, max value is current time +60 days.
protocol: string, mandatory. Describes the protocol version to be used when posting the response. Currently, must be set to "1.0".
opaque: string, mandatory. A reference that Freja eID must return to the relying party upon a successful identity assertion completion. Note that Freja eID makes no attempt to interpret the opaque data. For a given relying party, the opaque data must be unique and non-repeatable. Should Freja eID receive a new request with opaque data identical to a current transaction, the pending request will be silently cancelled and overwritten by the latter one. Initiating a transaction with opaque data that Freja eID already considers completed will result in an error displayed within Freja eID app (see 3.0 Draft Freja eID Relying Party Developers' Documentation below). Max value is 128 characters.

 

Example request:

Field
Value
Header

"alg":"HS256"
"kid":"RPNAME_KID"

Payload

"exp":1493806530000
"opaque":"ABCDEFGHIJKLMNOPRSTUVWXYZ012345678901234"
"proto":"1.0"
"iarp":"RPNAME"

Key value
(hexadecimal format)

000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f

Final JWS (compact
format, line broken
for clarity only)
Code Block
eyJraWQiOiJSUE5BTUVfS0lEIiwiYWxnIjoiSFMyNTYifQ.eyJleHAiOjE0OTM4MDY1MzAwMDAs
Im9wYXF1ZSI6IkFCQ0RFRkdISUpLTE1OT1BSU1RVVldYWVowMTIzNDU2Nzg5MDEyMzQiLCJwcm9
0byI6IjEuMCIsImlhcnAiOiJSUE5BTUUifQ.ys4o7XQE4v43pKjbtFowg9o9TDQAAKXR39uBssF
Grfo

 

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
4000Decoding of JWS encoded iaRequestData failed. For example, it could not be separated into header, payload and signature parts.
4001Cannot perform JWS validation.Reason could be unsupported algorithm.
4002Validation of JWS digital signature failed. Reasons could include modifications of the JWS document after signing or a wrongly constructed signature.
4003Invalid signer. For example, unknown keyid.
4004Decoding of payload failed.
4005Invalid expiry time.
4006Unknown identity assertion relying party.
4007Unknown protocol.
4008Identity assertion relying party mismatch with specified keyid.
4009Relying party not subscribed to identity assertion.
4010Request already completed.
4011The 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

Code Block
{
  "x5t": "SHA-1 digest of the signing certificate",
  "alg": "algorithm used to secure the JWS"
}

x5t: mandatory, Base64URL encoding of the certificate's SHA-1 digest.
alg: mandatory, value shall be RS256 which corresponds to 'RSA PKCS#1 signature with SHA-256'.

 

JWS Payload

Code Block
{
"ref":"transaction reference",
"opaque":"Opaque data as submitted in request",
"country":"Country related to social security number"
"ssn":"Social security number"
}

ref: string, mandatory. Unique service transaction reference that can be used for further investigation related to the call.
opaque: string, mandatory. Opaque data as submitted in the original identity assertion request.
ssn: string, mandatory. Contains the social security number (SSN) associated with the vetted person whose identity is asserted through the response.
country: string, mandatory. Contains the ISO-3166 two-alphanumeric country code of the country where the SSN is issued.

Example data:

Field
Value
Certificate info

See above.

Header

See above.

Payload

"ref":"1234.5678.9012.3456"
"opaque":"ABCDEFGHIJKLMNOPRSTUVWXYZ012345678901234"
"ssn":"199010101010"
"country":"SE"

Final JWS (compact
format, line broken
for clarity only)

(header omitted for brevity)

Code Block
eyJyZWYiOiIxMjM0LjU2NzguOTAxMi4zNDU2Iiwib3BhcXVlIjoiQUJDREVGR0hJSktMTU5PUFJ
TVFVWV1hZWjAxMjM0NTY3ODkwMTIzNCIsInNzbiI6IjE5OTAxMDEwMTAxMCIsImNvdW50cnkiOi
JTRSJ9.u1V8x-yxGtU10zIvWF_RK6l_Tfrk3zWajhuvMICGDnWN3hYZCzfSGHG3oerrbMIXPhET
48BEufWFJE0zQbWxBGXLAru9lvWsQoaYPBJJAuVZMj-ZV1-PhUgtONrVfGuSJR6cVRj42IxyUtw
ZEecbw37Dnip3KDkllZ5_WOSZEhJsC8lxyIYfAF7lD9q2Ln4wgZiTRJSe8KGJiat4c7jd__RlHu
AE7GPZ7aQcN_nqdBWrDK8SufvESQJQxW8LrAAwb0bWvT5R3hOSAMMx6BWhCZewnb7UYabSuZO06
6tDGOMbjTqGBaM9MmuRzVU452mOr1EGrkbHKlltqUw3gYFpOQ 

 

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 OKSuccess, additional information is available in the body.
204 No ContentSuccess, no additional information is available in the body.
400 Bad RequestThe request is malformed. For example, the body cannot be parsed.
404 Not FoundRequested resource does not exist.
410 GoneRequested resource is no longer available. For example, an obsolete API version.
422 Unprocessable EntityValidation or processing errors. Additional information is available in the body. If the input is corrected, the request can be resubmitted.
500 InternalservererrorThe 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

...

Image Removed

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
Code Block
{
   "userInfoType":"User info type",
   "userInfo":"User information corresponding to user info type",
   "askForBasicUserInfo": true,
   "restrict":"Restricts the login request to a specific mobile device",
   "minRegistrationLevel":"Minimum required registration level of a user"
}

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).

Note

Note: Not supported in current version of Freja eID.

minRegistrationLevel: string, optional. Minimum required registration level of a user in order to approve/decline authentication. If not present, default level will be BASIC.

Note

Note: Currently only BASIC minRegistrationLevel is supported.

ssnuserinfo
Code Block
{
"country":"Country of SSN",
"ssn":"Social security number of the end user"
}

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".
ssn: string, mandatory. Expected SSN of the end user as per pre-registration. If country equal to "SE", the value must be the 12-digit format of the Swedish "personnummer" without spaces or hyphens.

custuserinfo
Note

Reserved for future use, not supported in current version of Freja eID.

 

Possible errors returned by the method are the following:

Return code
Explanation
1001Invalid or missing userInfoType.
1002Invalid or missing userInfo.
1003Invalid restrict.
1004You are not allowed to call this method.
1005The user has not enabled your service.
1007Invalid min registration level.
2000Authentication request failed. Previous authentication request was rejected due to security reasons.
2001The 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
Code Block
{ 
   "authRef":"Reference to be submitted in getAuthResults method"
}

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
Code Block
{
   "authRef":"Authentication reference"
}

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
1100Invalid 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:

...

JSON Response Value in body

...

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.

...


...

Signature services

Freja 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 types

Freja eID allows for several types of signatures.

Simple signature type

The 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 type

The 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 type

The 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:

Section
bordertrue


Column
width20%


This page:

Table of Contents
stylecircle

Related pages:

Anchor
topOfThePage
topOfThePage

 

Example data for APPROVED response, JSON response body:

Column
width80%


Info
iconfalse

Copyright Statement

The specifications and information regarding the product in this manual are subject to change without prior notice. All statements, information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind, expressed or implied. Users must take full responsibility for their use of any products.

© 2017-2024 Freja eID AB. All rights reserved.

Introduction

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 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 (RPs), 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 LOA1, also known as Freja eID Basic. At this level a user will have confirmed an email address, 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, end users may opt for an extended registration process in order for their identity to be assured to LOA2 or LOA3: if the end user opted for an extended registration process,

  • For LOA2, users need to undergo a verification process with their ID document within the Freja eID app, as well as face enrollment;
  • For LOA3, also known as Freja eID Plus, users need to do an in-person identity check, whereby their real-life identity is connected to their digital identity. The assurance here being the physical ID document that was verified for LOA2.

These users (both those verified for LOA2 and LOA3) can then be referred to through their social security number (SSN). In Sweden, this would equate to having established a "personnummer" for the end user. Also, these users can be involved in interactions with web parties that involve login, but also legally binding signatures.

For easier integration, Freja eID also makes a distinction between Relying Parties, depending on the way they can integrate with us:

  • Stand-alone Relying Party - a Relying Party that wants to integrate with us on their own behalf;
  • Integrator Relying Party - a Relying Party that usually acts on behalf of their own customers, i.e. other organisations with their own branding, but can also integrate with us on their own behalf;
  • Integrated Relying Party - a Relying Party which is not connected with Freja eID system directly, rather via the Integrator Relying Party.

Read more about how Integrator and Integrated Relying Parties can integrate with Freja eID in Integrator Relying Party Management.

This document contains instructions for enabling Relying Party 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 Relying Parties: Authentication Service, Signing Service, and Organisation ID Service. Our recommendation is to read the sections of interest to you in their entirety at least once. On later occasions, use the links to quickly navigate to the section of interest.

Document Versions

VersionDateComment
5.222024-03-04Added new method to Organisation ID - Update Organisation ID; added new attributeToReturn: DOCUMENT_PHOTO.
5.212023-12-11Added new parameter called userConfirmationMethod.
5.202023-05-10Added Custodianship Service with a new method to retrieve user custodianship status.
5.192023-02-24Added DOCUMENT as attribute to return and requestAttributes parameter in Authentication and Signature Services, as well as Authentication and Signature Services as part of Organisation ID.
5.182022-11-09Supported XML_MINAMEDDELANDEN advanced signature type.
5.172022-10-10Supported INFERRED user info type for SIGN transactions.
5.162022-09-15Supported identifier display types and additional attributes for Organisation ID
5.152022-03-11Added ORGANISATION_ID as attribute to return and requestAttributes parameter in Authentication and Signature Service.
5.142021-12-15Added DOCUMENT as attribute to return and requestAttributes parameter in Authentication and Signature Service.
5.132021-10-21Added PHOTO as attribute to return and requestAttributes parameter in Authentication and Signature Service.

5.12

2021-09-01Supported ANY organisation Id issuer when requesting Organisation ID.
5.112021-05-27Added COVID_CERTIFICATES as attributeToReturn and requestAttributes parameter in Authentication and Signature Service.
5.10

2021-02-22

Added AGE as attributeToReturn and requestAttributes parameter in Authentication and Signature Service.
5.92021-01-26Added REGISTRATION_LEVEL as attributeToReturn and requestAttributes parameter in Authentication and Signature Service.
5.82020-11-09Added ALL_PHONE_NUMBERS to attributeToReturn and requestedAttributes parameter in Authentication and Signature Service.
5.72020-08-03Introduced new method in the Organisation ID Service - Get all Organisation ID users.
5.62020-05-15Introduced new JWS certificate for test and production environments.
5.52020-04-22Added ALL_EMAIL_ADDRESSES to attributeToReturn and requestedAttributes parameter in Authentication and Signature Service.
5.42020-04-02

Added ADDRESSES to attributesToReturn and requestedAttributes parameters in Authentication and Signature Service.

5.32020-02-28Changed the maximum length of Organisation ID title from 20 to 22 characters and Organisation ID identifier name from 25 to 30 characters. 
5.22020-02-05Changed the maximum length of Organisation ID identifier to 128 characters.
5.12019-12-19Added INTEGRATOR_SPECIFIC_USER_ID to attributesToReturn and requestedAttributes parameters. This attribute can be requested only by Integrator Relying Parties. 
5.02019-12-10Expanded Organisation ID Service to support initiation of Authentication and Signature requests for a user using the previously added Organisation ID. Adding a custom title of the Organisation ID and the identifier name is now supported. 
4.82019-11-18Introduced a new error code to inform when the userInfo requested in the authentication or signature request does not exist in Freja eID database.
4.72019-10-23Added Troubleshooting section to Implementation - Troubleshooting and Best Practices.
4.62019-10-01Included Organisation ID Service.
4.52019-01-10userInfoType can now be set to INFERRED. Added EMAIL_ADDRESS to attributesToReturn and requestedAttributes parameters in Authentication and Signature responses.
4.42018-10-04minRegistrationLevel can now be set to EXTENDED.
4.32018-09-25

Added DATE_OF_BIRTH and RELYING_PARTY_USER_ID to attributesToReturn and requestedAttributes parameters in Authentication and Signature responses. Added RP_CANCELED to status string in Authentication and Signature responses.

4.22018-07-23Added support for PHONE as userInfoType and Extended signature types (see Signature Services). Defined changes to the attributesToReturn parameter for returning attributes BASIC_USER_INFO and SSN in responses.
4.12018-06-05

Added support for returning two more user attributes in the Authentication Services - SSN (personal identity number) and integratorSpecificUserId (a unique user identifier, specific for a particular Integrator RP)
Added instructions on how to obtain client TLS/SSL certificate to access Freja eID services.

4.02018-03-29

Included Integrator Relying Party Management. Included Custom Identifier Management and updated the support for requesting additional user attributes when initiating the authentication accordingly. Added support for cancelling an authentication or a signing request. Added example requests for all methods in all the services. Updated the custom URL scheme for automatic launch of Freja eID app.

3.02018-01-19Changed the endpoint URLs for all Authentication Service methods. Adjusted error codes in Authentication Service. Included Signature Service.
2.62017-11-01Added support for requesting additional user attributes when initiating the authentication.
2.52017-09-13Changed the JWS header value from x5c to x5t.
2.42017-08-10Changed the URL for posting the response for identity assertion.
2.32017-08-03Opaque data must be max128 characters long. Adjusted identity assertion error codes.
2.22017-06-30Adjusted error codes for validation errors. Instead of generic error 1000 and list of specific errors, specific error is returned directly.
2.12017-06-23Adjusted error codes to comply with conventions within other services.
2.02017-05-29Included Authentication Service. Changed examples to use signing certificate under Freja eID TEST root.
1.02017-04-26This document is a preliminary version. The content of this document is still under review and subject to change.


Abbreviations

CACertificate Authority
CSRCertificate Signing Request
eIDElectronic Identification
JSONJavaScript Object Notation
JWSJSON Web Signature
PSKCPortable Symmetric Key Container
PKIPublic Key Infrastructure
RESTRepresentational State Transfer
RPRelying Party
RSA (cryptosystem)Rivest–Shamir–Adleman
SSL/TLSSecure Sockets Layer/Transport Layer Security
SSNSocial security number (''personnummer'' in Sweden)


Getting started  

About Freja eID environments

The Freja eID system offers two environments:

  • Test or Demo Environment, which is designed for testing purposes, it is intended to be used by Relying Parties during the process of integration with Freja eiD to test the integrated services.
  • Production Environment, which is where the Freja eID services are actually available for business use and where the real-time staging of integrated services is executed.

Note that the Test Environment resembles the Production Environment as much as is possible in all segments.

Before you begin

Test environment checklist

There are several technical requirements that must be in place before the integration with Freja eID can start. Before proceeding, you need to:

  • Obtain an SSL/TLS client certificate providing you access to the Freja eID Test Environment. For more information, refer to the Certificates section.
  • Import Freja eID Test root certificate as trusted in the trust store of your application.
  • Using Freja eID mobile application, register one or more users with the Freja eID Test infrastructure.

Production environment 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, a URL and a short description. Please note that:
    • The logo must be delivered in one of the vector file formats: AI (Adobe Illustrator Artwork), EPS (Encapsulated PostScript) or editable PDF (Portable Document Format). The preferable format is AI (filename extension is .ai).  
    • The display name is restricted to the maximum length of 100 characters and the description should not exceed 500 characters. The URL can be up to 100 characters long.
  • Obtain an SSL/TLS client certificate providing you access to the Freja eID Production Environment. For more information, refer to the Certificates section.
  • Import Freja eID Production root certificate as trusted in the trust store of your application.

Anchor
Certificates
Certificates
Certificates in Freja eID

Freja eID system requires the usage of SSL/TLS certificates for communication with Relying Party applications. The following certificates are used:

  • Freja eID's server certificate:
    • Freja eID Test root certificate
    • Freja eID Production root certificate
  • Relying Party's client certificate:
    • Test client certificate
    • Production client certificate

Additionally, JWS certificates are used to digitally sign the results of authentication and signature requests.

Server SSL certificate

Freja eID Server certificate is used so that Relying Parties can authenticate Freja eID as trusted in their environment. Freja eID's Server certificate should be imported in the trust store of the Relying Party's application. There are two server certificates which you need to use:

  • Freja eID Test root certificate, when you want to start the integration in the Test Environment
  • Freja eID Production root certificate, when you want to execute your integration in the Production Environment

Below are Freja eID's Test and Production root certificates, PEM encoded:

Test server root certificateProduction server root certificate

-----BEGIN CERTIFICATE-----
MIIGMzCCBBugAwIBAgIUPB4rUqFFiG6g67a+cLCBCuTkxGQwDQYJKoZIhvcNAQEL
BQAwUTELMAkGA1UEBhMCU0UxEzARBgNVBAoTClZlcmlzZWMgQUIxEjAQBgNVBAsT
CUZyZWphIGVJRDEZMBcGA1UEAxMQUlNBIFRlc3QgUm9vdCBDQTAeFw0xNzA1MTAx
NDI2MDBaFw00NzA1MTAxNDI2MDBaMFExCzAJBgNVBAYTAlNFMRMwEQYDVQQKEwpW
ZXJpc2VjIEFCMRIwEAYDVQQLEwlGcmVqYSBlSUQxGTAXBgNVBAMTEFJTQSBUZXN0
IFJvb3QgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC6n6IvJcOI
y9y4x4YZlcDYWGANZn/58aQq/+q/2IOheqH7pfqf00FrZmTFzXQTI4koPUOpagYM
ESG6MLlgW7akCnA3V5duEvGBJgAR6FldaiwdHMqWBKLb5pvoC2/uczSNie+pEidQ
uj+Oh5MwUCJWx4n2fLoJMTP4Lb1nxFQXzCjRMWJ1w3pM+3mDYJzvLFhV2Ur7QBAd
JjGGPCprDdREfzanm7Jg5mFtdtbMPPobMVDKRiCvfXLavE4UeupJF2Rdg530tpaJ
Mb6m++OsFMN4sHq0HUYiYIwetdmxY3W2dpKJjmL7pPPprcpnHqci9a3N32ajclpV
Z7c0jfuwCwk+6EFYRNmCkKEkMrSe8wr8tuH4FYwhTQCsFQeAWUaWzSl29Ielmx38
Ot+g3aUw8LZltZzMYhak257bx4Lqfr23edjz2g45/DEk5H2/zsvEGnwq73xtpAJZ
rZHSqgugwPqLhCxKs93abuShMas92CL7juAp4FjYzjBS85qQnHhxVFziGoyvtUU3
YS6ZNae96KbgW7Kjd72i/wfUNJKdF2QAKWIJYL80bQ9m2w+sL6TNd/tRG3OXWJHD
prKRTYKiW2nZxDoX4ClsNMWj2iKPaGtbl6tmZpRLZtjs8s9lAiNBQd0XqtTsyyr/
3+8Afnhs+DG55A4/91DdaXlDA4UbpjZpDQIDAQABo4IBATCB/jAOBgNVHQ8BAf8E
BAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBAzCBuAYDVR0gBIGwMIGtMIGqBgUqAwQF
BjCBoDA4BggrBgEFBQcCARYsaHR0cHM6Ly9jcHMudGVzdC5mcmVqYWVpZC5jb20v
Y3BzL2luZGV4Lmh0bWwwZAYIKwYBBQUHAgIwWAxWVGhpcyBjZXJ0aWZpY2F0ZSBo
YXMgYmVlbiBpc3N1ZWQgIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgRnJlamEgZUlE
IFRFU1QgUG9saWN5IENvbnRyb2wwHQYDVR0OBBYEFMqw7LlXw5w9rTmKE/rwNbrs
DHeKMA0GCSqGSIb3DQEBCwUAA4ICAQBOGI2Y4uXQeAMSswESsIsbF4RlkvIQiGCd
kwt7OzpfiRcOQnkxm9rlpdPtC7MajVI6owtZwT6BSG0jmyUFLihp4VB02VM02xkc
YsSD/58V+Gf/1iEjgQgnNjz9Z5bURGUiPK9TWrchi7E2MLlySeHAEJUU1u5hwU0V
+0hQ4S+EEZBYfOV5WaoFma2YXFTSSCHtzmG+OMhItgevJFt+OLymOTewuF7v4vcP
PVyUB9iEgawEwpjJEBtaxkmIaJv4J/c92KKHcTKxr8EaPfOl4t3UCHmQLgnCEG/3
Hn6KgNsH6RCOmZojdTf5vwQZ2B7AcbVozU/noJZ1o6C4oRt5PkTEdSnAmX8pf4Mn
NXYmxPpXE7KlEazLx9poBGVobCn0X3F+1A5pEHfY8Oy/EOKc3+ZswW294AuWCs/n
HlamWPS+jqNKW3qjjNK6FZs72IECuf9OSN5BvDrUsW44b0Y6oGIUevOtexAXiBWV
SKT9GsojrlY36X0O3+lkkqtW4aea11qi3oGz+9iXcPQeeD7kgfkszSYKkn9WB1YT
j/lpZTlf9DlxA5++uu3Grpx7qRdClEbDf5Q2HLISWVwirocySGzh4wACFHi6iQjn
srnzHu968MtOnN6FQt9zPZxaRYrzLpV/9yyah9jYYuLFIGje+yzAn5M8ORV5p1At
FvjTRfH5oA==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIGKTCCBBGgAwIBAgIURVYm7hoZF4XSX/iKAN5xmB+3qF4wDQYJKoZIhvcNAQEL
BQAwdjELMAkGA1UEBhMCU0UxHTAbBgNVBAoTFFZlcmlzZWMgRnJlamEgZUlEIEFC
MRMwEQYDVQQLEwpQcm9kdWN0aW9uMR0wGwYDVQQDExRGcmVqYSBlSUQgUm9vdCBD
QSB2MTEUMBIGA1UEYRMLNTU5MTEwLTQ4MDYwHhcNMTcwODAxMTEzNzUwWhcNNDcw
ODAxMTEzNzUwWjB2MQswCQYDVQQGEwJTRTEdMBsGA1UEChMUVmVyaXNlYyBGcmVq
YSBlSUQgQUIxEzARBgNVBAsTClByb2R1Y3Rpb24xHTAbBgNVBAMTFEZyZWphIGVJ
RCBSb290IENBIHYxMRQwEgYDVQRhEws1NTkxMTAtNDgwNjCCAiIwDQYJKoZIhvcN
AQEBBQADggIPADCCAgoCggIBAKXB6WuJuqYlZQzRHWAxG4WI8WzwK0h8A4V7mL+x
LNH9dW5WykdKiC9WOrYq2bUYB5KJofMvsUMnmcbOmoTjNikBUvI88CZjinqpSd0O
kCEIHrEeNrk8C9tkNf6v879nsqr94k9uJj665OrRZinkTW+bxAWnYiEH1tNrc/Wj
nUWXR5pwZnDhO4m/fOHCR92LR5cP9zZ7DDBFPXqtTXURrXSyhoXn+/yKX/ubBeN4
OHorjS7cywEzyQkhvYSSIf1ypmDpRuBoL+sMKapCHgIrPcWeCMR0SHFaKxDe1bqL
Y59OKRcRBrm5Ec9RnJcnOT8DZoDQqWGDZ6GsSRuHlW5xkhhzrdlB6Lrw1avPcCvx
4/ZQTFLOZm+zpltUCG7Q/z9HzihGn0bqcrm1PYKQmRpTlwcqfgNGOConnNOkLW7h
+8szIR4xIpT6MroAZTrvwWi43Db35TQWZkPQ9NKKUmc98KN3cqcIvtjrLArK1nlS
9Juf30oQrU4lQbfod9NZYC/U03aonYd514wpz/mwtVFkY9zZfNfkfGmSwMGycexn
bBh5swIZYUvkmtdDZsHGXjJIsIFD4AI6NODRvyXvgLRDabvrqia22+cEvJ/eIQIK
hKm8Kvo3Y28g1oZPuePLZZkFeKHluBDsgBsJJspyIlYHS3s7YfBkhmzKDkH4JZaf
Pl/nAgMBAAGjga4wgaswDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w
HwYDVR0jBBgwFoAUtHJ2xk4gUzOKnP0zaascRhQzY+MwSAYDVR0gBEEwPzA9Bggq
hXCBeQEBATAxMC8GCCsGAQUFBwIBFiNodHRwczovL3d3dy5mcmVqYWVpZC5jb20v
dGMvY2EuaHRtbDAdBgNVHQ4EFgQUtHJ2xk4gUzOKnP0zaascRhQzY+MwDQYJKoZI
hvcNAQELBQADggIBAGYhB+/Imju88U+TBz0ddO71aaO9otqvsAQFpVwXDERTqwG6
Z/3dXUZYWaP02CA6zRG7hy8o/EfkrDGyluNsUvN8XAskulCvhKNvQ86Rv1fEq6/v
kNeg+fhkF70R4NPAOmZm5uiho2QUT45gXPo16ICK9kCdLYdN6HrCK7/d+0bMDigH
moTlSvq8G50rpKcvxEBdwy7zAfYZ+p1B6gLV7ulUJot5fZ5+RG/mD3tmWHi2bQid
lsi3MM9Tpw1XWjimLSsdjXbV0LOzGVRcB4xbvDxM4OfR3zTCxJpdqE/9jLNVNr5O
IVqj3P+K3dU6ydj+RMjJILpRU+Po4YEhv32VFyITiX+n7GKXN2n7Sp13/6/UCgxe
cqBIuI+UK7F7c+ZKNY1RBh0uoIc/2hFkQNUz8R9LmTzex20Y0RhW9fq2cuNxp9vJ
IMPOiHsggGCn6hwf0RY94VDxGIhSAkzSVvfaiLZYejN2Xu/C2ym9wUd0QauBTpXO
mgIV38CMwmtbSKLxPqfEbgpk6+/An5HO3u4XoxKYroL8JuuKsZBxbQyiPmOZVeNg
uXExHmZhcayFRXMs4xJMXE1W1zj+zTsGa57QxFWfgH6FPfY2PG5Z/0MiBEMlS1V5
Q25JHHI64kWnkynGymYL2veqVOYxuJm2Jmzwkeequ5+pi814HCHGwjMpT60N
-----END CERTIFICATE-----

Client SSL certificate

As mentioned before, to access and use Freja eID services, you need to obtain a client SSL/TLS certificate. Two client certificates are needed, one for access to the Testing Environment and one for access to the Production Environment. Client certificate authenticates your application when it tries to communicate with Freja eID services. Additionally, Freja eID uses your Client certificate to identify you in its system when you try to send an authentication or signing request.

The following section provides you with instructions on how to generate an SSL/TLS key and a certificate signing request (CSR), which you can then send to Freja eID partner support to provide you with the ready-made client certificate. It also documents how to create a PKCS#12 file.

Note
iconfalse

For this purpose, we used OpenSSL, an open-source cryptography and SSL/TLS toolkit. For more information about OpenSSL, please refer to their official website. Of course, you can use any other CSR generator. 


What is an SSL/TLS key and what is it used for?

The SSL/TLS key is a part of the Public Key Infrastructure (PKI) that is generally used in case of SSL/TLS certificates. A Public Key Infrastructure assumes asymmetric encryption, where two types of keys are used: a Private Key and a Public Key (included in an SSL/TLS certificate). The private key is based on the RSA algorithm and is used for authentication and the establishment of an SSL/TLS session. Since encrypted data transmission takes too much time in case of asymmetric encryption, this kind of encryption is only used for a secure exchange of the symmetric key, which is used for actual transmitted data encryption and decryption. 

What is a certificate signing request (CSR)?

A certificate signing request (also CSR or certification request) is a block of encoded text that is given to a certificate authority (CA) when applying for an SSL/TLS certificate. It is usually generated on the server where the certificate will be installed on and contains information that will be included in the certificate, such as the organisation name, common name (domain name), locality and country. It also contains the public key that will be included in the certificate. The private key is usually created at the same time as the CSR, thus making a key pair. A CSR is generally encoded using ASN.1, according to the PKCS #10 specification.

Distinguished name

SSL/TLS certificates contain identifying information, such as the qualified domain name used for DNS lookups of your server (also called Common Name), your organisation or company name and location information. This information is called the certificate's Distinguished Name. When generating a CSR on your server, you are asked to enter the Distinguished Name, which uniquely identifies your server.

Below is an example list of required fields for the Subject's Distinguished Name used when generating a CSR request for a Freja eID Relying Party named "ACME AB".
Please note that the fields must be encoded as ASN.1 UTF8String in order to be correctly processed by the Freja eID CA.

DN fieldNameExplanationExample
CNCommon Name(Optional) Function qualifier, if required.Document signing service
OUOrganisational Unit(Optional) Internal organisational qualifier, if required.Production
OOrganisation NameLegal name of the organisation, as registered with the company register of the country it operates in.ACME AB

OID (2.5.4.97)

Organisation identifierOrganisational number, as registered with the company register of the country it operates in.556677-8888
CCountryThe two-letter ISO abbreviation of the country the company operates in.SE


Note
iconfalse

The following characters cannot be used in the Organization Name or the Organizational Unit: < >~ ! @ # $ % ^ * / \ ( ) ?.,&

Client certificate generation - Step-by-step guide

  1. Launch Open SSL (preferably on the production server) and generate your private key with the genrsa command (see below). Command arguments are the location and file name where you wish to store your key and the key strength (with the minimum value of 2048 bits). You will also be prompted to choose a secure passphrase for the key.

    Code Block
    openssl genrsa -F4 -aes256 -out <PATH_TO_YOUR_PRIVATE_KEY>.key 2048


    Warning
    iconfalse
    titleSecurity recommendations

    As the security relies on the integrity and security of this private key, it is the best practice to generate the key on the production system itself and also to make sure that this key is protected duly against unauthorised attacks by limiting access to the key file itself. Once the PKCS#12 file has been generated, the key file can be removed or stored securely offline for backup purposes.


  2. Next, generate the CSR using the key generated in step 1 with the following command and put it in a file.

    Code Block
    openssl req -new -subj "/C=SE/2.5.4.97=556677-8888/OU=Production/O=ACME AB/CN=Document signing service" -key <PATH_TO_YOUR_PRIVATE_KEY>.key -out <PATH_TO_YOUR_CSR>.csr


  3. Compress the file with ZIP/gZIP and email it to partnersupport@frejaeid.com. After the certificate is issued by the Freja eID Support, you will receive a ZIP file with your new certificate, along with required Freja eID CA certificates.

    FilenameDescriptionDistinguished NameIssuer
    Freja eID Production Root.cerFreja eID's offline root certificate

    CN = Freja eID Root CA v1

    OU = Production

    O = Verisec Freja eID AB

    2.5.4.97 = 559110-4806

    C = SE

    CN = Freja eID Root CA v1

    OU = Production

    O = Verisec Freja eID AB

    2.5.4.97 = 559110-4806

    C = SE

    Freja eID Production Issuing CA.cerFreja eID's Issuing Certificate Authority

    CN = Freja eID Issuing CA v1

    OU = Production

    O = Verisec Freja eID AB

    2.5.4.97 = 559110-4806

    C = SE

    CN = Freja eID Root CA v1

    OU = Production

    O = Verisec Freja eID AB

    2.5.4.97 = 559110-4806

    C = SE

    Freja eID Production Certificates.pemFreja eID certificate chain. Contains booth root and CA certificates

    <YOUR CERTIFICATE>.cerYour relying party issued certificate

    CN = Document signing service

    OU = Production

    O = ACME AB

    2.5.4.97 = 556677-8888

    C = SE

    CN = Freja eID Issuing CA v1

    OU = Production

    O = Verisec Freja eID AB

    2.5.4.97 = 559110-4806

    C = SE


  4. Generate the PKCS#12 keystore file with the following command and choose a secure passphrase:

    Code Block
    openssl pkcs12 -aes256 -CAfile "Freja eID Production Certificates.pem" -export -in <YOUR CERTIFICATE>.cer -inkey <YOUR_PRIVATE_KEY>.key -out <YOUR_KEYSTORE>.pfx


    Warning
    iconfalse
    titleSecurity recommendations

    As the security relies on the integrity and security of this keystore, create it on the production system and protect it the production system itself and also make sure that this key is protected duly against unauthorised attacks by limiting access to the keystore file itself.


  5. Verify connectivity against production with the following command:

    Code Block
    openssl s_client -verify_return_error -CAfile "Freja eID Production Certificates.pem" -cert <YOUR CERTIFICATE>.cer -key <YOUR_PRIVATE_KEY>.key -connect services.prod.frejaeid.com:443


    Warning
    iconfalse
    titleReminder

    Once connectivity has been verified, files from the ZIP file should be deleted to avoid misunderstandings.


Anchor
JWS
JWS
JWS certificate


Freja eID uses JWS to validate end users' signatures. Signatures created by the end users are PKI-based and therefore non-repudiable. Upon completion of the signature by the end 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.

JSON Web Signature (JWS) represents digitally signed content using JSON data structures and BASE64URL encoding. JWS has the following structure:

  • JOSE Header
  • JWS Payload
  • JWS Signature

There are two different serializations for JWSs: a compact, URL-safe serialization called the JWS Compact Serialization and a JSON serialization called the JWS JSON Serialization. In both serializations, the JWS Protected Header, JWS Payload, and JWS Signature are BASE64URL encoded.

In Freja eID, the JWS Compact Serialization is used and a JWS is represented as the concatenation:

BASE64URL(UTF8(JWS Protected Header)) ||

'.

' ||
BASE64URL(JWS Payload) ||

'.

’ code

' ||
BASE64URL(JWS Signature)

 

JWS Protected Header

Example JWS signature:
{

"

x5t

userInfoType":

"SHA-1 digest of the signing certificate", "alg": "algorithm used to secure the JWS" }

x5t: mandatory, Base64URL encoding of the certificate's SHA-1 digest.

alg: mandatory, the value shall be RS256 which corresponds to 'RSA PKCS#1 signature with SHA-256'.

 

 

JWS Payload

Code Block
{
   "authRef":"Authentication reference",
   "status":"Authentication status",
   "userInfoType":"User info type",
   "userInfo":"User information corresponding to user info type",
   "basicUserInfo":{"name":"user's name","surname":"user's surname"},
   "timestamp":"Time when authentication confirmed by end user"
}

authRef: See authRef above.
status: See status above.
userInfoType: See userInfoType as described in 3.0 Draft Freja eID Relying Party Developers' Documentation.
userInfo: See userInfo as described in 3.0 Draft Freja eID Relying Party Developers' Documentation.
basicUserInfo: JSON structure, optional. See basicUserInfo below.
timestamp: long, mandatory. Describes the time when the confirmation by the end user was validated on Freja eID server side. Expressed in milliseconds, since January 1, 1970, 00:00 UTC.

basicUserInfo
{
    "name":"User's name",
    "surname":"User's surname"
}
Code Block
{
"authRef":"12345-67890-abcdef",
"status":"APPROVED",
"details":"JWS content as per below",
"basicUserInfo": {
                   "name":"John",
                   "surname":"Doe"
                 }
}
Field
Value
Certificate info

See above.

Header

See above.

Payload

"authRef":"12345-67890-abcdef"
"status":"APPROVED"
"userInfoType":"EMAIL"
"userInfo":"john.doe@somedomain.com"
"basicUserInfo":{"name":"John","surname":"Doe"}
"timestamp":"12345-67890-abcdef" 

Final JWS (compact
format, line broken
for clarity only)

(header omitted for brevity)

Code Block
eyJ1c2VySW5mbyI6ImpvaG4uZG9lQHNvbWVkb21haW4uY29tIiwidXNlckluZm9UeXBlIjoiRU
1BSUwiLCJiYXNpY1VzZXJJbmZvIjp7InN1cm5hbWUiOiJEb2UiLCJuYW1lIjoiSm9obiJ9LCJh
dXRoUmVmIjoiMTIzNDUtNjc4OTAtYWJjZGVmIiwic3RhdHVzIjoiQVBQUk9WRUQiLCJ0aW1lc3
RhbXAiOjE0OTEzODgxNjMzODl9.p7jFO0m3iZF84edbZtzvy5qLWnsNAVzZZ2QoW9FnZ3qSvS3
iWEAFoIfqyQHNbNHfjavQ90224k89DMHoe2IPEnDR7TiDzOEna8GTM9rRcRZcARrNYclzqMtgl
J3hdxK0yyrk2P553wQJLqrYTft3DlJKVAuxmpCh3fcr-FfN5qiHrK7gCm60660zFJFV76AwTbt
4mlanlOLVUE5rvE4Yb2Fh7u6Ls3HVz1zOyFW0geA-cJjL0PhUeXpHKaiRFBYog_oO0uYf9V37j
QhzlV_FfDIVWSwm6jw-ZqwF__HSx2LpT4sVp0f5XfRZZCvR3Gj3AauaXLmrv7rWR1VO1WC7Uw

Get authentication results method

The 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:

System
Method endpoint
Test
https://services.test.frejaeid.com/authentication/1.0/getResults
Production
https://services.prod.frejaeid.com/authentication/1.0/getResults

 

The parameter of the method is a Base64 encoded JSON payload according to the following:

Parameter name
Value
getAuthResultsRequest
Code Block
{
   "includePrevious":"Include previously returned results"
}

includePrevious: string, mandatory. Must be equal to ALL or OUTSTANDING_AND_NEW. If equal to ALL, indicates that the complete list of authentications successfully initiated by the relying party within the last 10 minutes will be returned, including results for previously completed authentication results that have been reported through an earlier call to one of the methods for getting authentication results. Sending OUTSTANDING_AND_NEW as the value will return only the status of outstanding (i.e. authentications still in progress) and completed but previously unreported statuses.

Note

NOTE: In the current implementation of the service must be equal to ALL.

Possible errors returned by the method are the following:

Return code
Explanation
1200Invalid or missing includePrevious parameter.

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
Code Block
{
"authenticationResults":[
    {
      "authref":"Authentication reference",
      "status":"Authentication status",
      "details":"JWS signed data, see below",
      "basicUserInfo":{
                        "name":"John",
                        "surname":"Doe"
                      }
    },
    {
      "authref":...
    }
  ]
}

authenticationResults: an array of JSON objects, mandatory. An array of authentication result objects (if the authRef parameter was passed, the array will always be of length 1).
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).
details: JWS signed object (see details as described in the 3.0 Draft Freja eID Relying Party Developers' Documentation above), optional.
basicUserInfo: JSON object (see details as described in the Get one authentication result method above), optional.

Anchor
topOfThePagetopOfThePage
Binary data type
Signature format
Value returned to the relying party
SHA-256 data digestRAWA JWS signature containing with the payload comprising of the raw digital signature (RSA transformation) over the digest data, alongside a reference to the end-user's certificate coresponding to the signing key, evidence of certificate status and information about the end-user's identity, all signed by Freja eID.
Opaque binary dataXML

An enveloping XML digital signature containing the data presented to the user and the opaque binary data, signed by the end user and counter-signed by Freja eID, alongside the information about the user's identity and evidence of the validity of the end user's signature.

Opaque binary dataCMSCMS digital signature containing the data presented to the user and the opaque binary data, signed by the end user, alongside evidence of certificate status and information about the user's identity. This signature is, in turn, counter-signed in CMS format in evidence of its validity.
XML documentXML

An enveloped XML digital signature over the supplied XML document extended with the data presented to the user, signed by the end-user and counter-signed by Freja eID, alongside the information about the user's identity and evidence of the validity of the end user's signature.

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 Signature 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 Sign Method

This 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:

System
Method endpoint
Test
https://services.test.frejaeid.com/sign/1.0/initSignature
Production
https://services.prod.frejaeid.com/sign/1.0/initSignature

The parameter of the method is a Base64 encoded JSON payload according to the following:

Parameter name
Value
initSignRequest
Code Block
{
   "userInfoType":"User info type",
   "userInfo":"User information corresponding to user info type",
   "restrict":"Restricts the signature request to a specific mobile device",
   "minRegistrationLevel":"Minimum required registration level of a user",
   "title":"Title to display in transaction list"
   "pushNotification": {
						 "title":"Title to display in push notification to user",
						 "text":"Text to display in push notification to user"
					   },
   "confidential":"true/false",
   "expiry":"Expiry time for the request",
   "dataToSignType":"Type of data to sign",
   "dataToSign":"The data to be signed",
   "signatureType":"Signature type"
}

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
Code Block
{
"country":"Country of SSN",
"ssn":"Social security number of the end user"
}

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".
ssn: string, mandatory. Expected SSN of the end user as per pre-registration. If country equal to "SE", the value must be the 12-digit format of the Swedish "personnummer" without spaces or hyphens.

custuserinfo
Note

Reserved for future use, not supported in current version of Freja eID.

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).

Note

Note: Usage of "restrict" is not supported in current version of Freja eID.

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.

Note

Note: In the current version of Freja eID, if the parameter is supplied, it must be set 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.

 

 dataToSignType 
dataToSign

SIMPLE_UTF8_TEXT

Code Block
{
"text":"Base64 encoded UTF-8 text displayed to the end user"
}

text: Base64 string, mandatory. The text that will be shown in the mobile application and signed by the end user. The content of the Base64 string are bytes representing a UTF-8 encoding of the text to be displayed to and signed by the user.

signatureType: string, mandatory. The type of signature that is requested. Currently, only SIMPLE is supported.

 

Possible errors returned by the method are the following:

Return code
Explanation
1001Invalid or missing userInfoType.
1002Invalid or missing userInfo.
1003Invalid restrict.
1004You are not allowed to call this method.
1005The user has not enabled your service.
1006Invalid confidential.
1007Invalid min registration level.
3000Invalid or missing dataToSignType.
3001Invalid or missing dataToSign.
3002Invalid or missing signatureType.
3003Invalid expiry time.

 

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
Code Block
{ 
   "signRef":"Reference to be submitted in getOneResult method"
}

signRef: string, mandatory. A reference unique to the transaction, that can be used to query the result of a specific signing transaction (see 3.0 Draft Freja eID Relying Party Developers' Documentation and 3.0 Draft Freja eID Relying Party Developers' Documentation below).

Methods for retrieving signature results

There 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 method

The method is called using HTTP POST through the URLs below:

System
Method endpoint
Test
https://services.test.frejaeid.com/sign/1.0/getOneResult
Production
https://services.prod.frejaeid.com/sign/1.0/getOneResult

 

The parameter of the method is a Base64 encoded JSON payload according to the following:

Parameter name
Value
getOneSignResultRequest
Code Block
{
   "signRef":"Signature reference"
}

signRef: string, mandatory. The value must be equal to a signature reference previously returned from a call to the 3.0 Draft Freja eID Relying Party Developers' Documentation. 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.

Possible errors returned by the method are the following:

Return code
Explanation
1100Invalid 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:

 
JSON Response Value in body
Response body
Code Block
{
   "signRef":"Signature reference",
   "status":"Signature status",
   "details":"signed data, see below"
}

signRef: string, mandatory. The signature reference of the signing request.
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), OPENED (the user has opened and seen the signature request but neither cancelled nor approved it yet), CANCELLED (the end user declined the signature request), EXPIRED (the signature request was not approved by the end user within the signature validity limit as requested when the signature was initialized), APPROVED (the signature was successful).

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

Code Block
{
  "x5t": "SHA-1 digest of the signing certificate",
  "alg": "algorithm used to secure the JWS"
}

x5t: mandatory, Base64URL encoding of the certificate's SHA-1 digest.
alg: mandatory, the value shall be RS256 which corresponds to 'RSA PKCS#1 signature with SHA-256'.

 

 

JWS Payload

Code Block
{
   "signRef":"Signature reference",
   "status":"Signature status",
   "userInfoType":"User info type",
   "userInfo":"User information corresponding to user info type",
   "minRegistrationLevel":"Minimum required registration level of a user",
   "timestamp":"Time when signature was confirmed by end user",
   "signatureType":"Signature type",
   "signatureData": {
      "userSignature":"The signature produced by the end user"
      "certificateStatus":"Evidence of end-users certificate status"
   }
}

signRef: See signRef above.
status: See status above.
userInfoType: See userInfoType as described in 3.0 Draft Freja eID Relying Party Developers' Documentation.
userInfo: See userInfo as described in 3.0 Draft Freja eID Relying Party Developers' Documentation.
minRegistrationLevel: See registrationLevel as described in 3.0 Draft Freja eID Relying Party Developers' Documentation.
timestamp: long, mandatory. Describes the time when the confirmation by the end user was validated on Freja eID server side. Expressed in milliseconds, since January 1, 1970, 00:00 UTC.
signatureType: string, mandatory. The type of signature that is requested. Currently only SIMPLE is supported.
signatureData:
see fields below, mandatory.
userSignature
: the produced signature, mandatory. Contains the end-user's signature in the requested format. The end-user's signature will implicitly contain the dataToSign as requested in 3.0 Draft Freja eID Relying Party Developers' Documentation as within its payload.
certStatus: Base64 string, mandatory. Contains the OCSP response regarding the state of the end-user certificate at the time of validating the signature. 

Get signature results method

The method is called using HTTP POST through the URLs below:

System
Method endpoint
Test
https://services.test.frejaeid.com/sign/1.0/getResults
Production
https://services.prod.frejaeid.com/sign/1.0/getResults

 

The parameter of the method is a Base64 encoded JSON payload according to the following:

Parameter name
Value
getSignResultsRequest
Code Block
{
   "includePrevious":"Include previously returned results"
}

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:

Return code
Explanation
1200Invalid or missing includePrevious parameter.

 

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
Code Block
{
"signatureResults":[
	{	
   		"signRef":"Signature reference",
   		"status":"Signature status",
   		"details":"signed data, see below"
	},
	{
		"signatureRef":...
	}
}

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).
signRef
: string, mandatory. The signature reference of the signing request.
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), OPENED (the user has opened and seen the signature request but neither cancelled nor approved yet), CANCELLED (the end user declined the signature request), EXPIRED (the signature request was not approved by the end user within the signature validity limit as requested when the signature was initialized), APPROVED (the signature was successful).

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).

 

"EMAIL","userInfo":"joe.black@verisec.com","minRegistrationLevel":"BASIC","title":"Sign transaction","confidential":false,"expiry":1517526000000,"dataToSignType":"SIMPLE_UTF8_TEXT","dataToSign":"{\"text\":\"VGhpcyBpcyBhIHRleHQgZm9yIHNpZ24gdHJhbnNhY3Rpb24u\"}","signatureType":"SIMPLE"}

If you wish to validate the JWS signature of transaction evidence supplied by Freja eID you must be able to handle multiple certificates for validation. Which certificate should be used for validation is indicated by the x5t field in the JWS Protected Header. The certificates for test and production are in the tables below alongside their respective x5t header values and validity times.

JWS certificates in test

Test JWS certificate x5tTest JWS certificateFrom/Until

HwMHK_gb3_iuNF1advMtlG0-fUs

-----BEGIN CERTIFICATE-----
MIIEETCCAvmgAwIBAgIUTeCJ0hz3mbtyONBEiap7su74LZwwDQYJKoZIhvcNAQEL
BQAwgYMxCzAJBgNVBAYTAlNFMRIwEAYDVQQHEwlTdG9ja2hvbG0xFDASBgNVBGET
CzU1OTExMC00ODA2MR0wGwYDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjENMAsG
A1UECxMEVGVzdDEcMBoGA1UEAxMTUlNBIFRFU1QgSXNzdWluZyBDQTAeFw0xNzA3
MTIxNTIwMTNaFw0yMDA3MTIxNTIwMTNaMIGKMQswCQYDVQQGEwJTRTESMBAGA1UE
BxMJU3RvY2tob2xtMRQwEgYDVQRhEws1NTkxMTAtNDgwNjEdMBsGA1UEChMUVmVy
aXNlYyBGcmVqYSBlSUQgQUIxDTALBgNVBAsTBFRlc3QxIzAhBgNVBAMTGkZyZWph
IGVJRCBURVNUIE9yZyBTaWduaW5nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAgMINs87TiouDPSSmpn05kZv9TN8XdopcHnElp6ElJLpQh3oYGIL4B71o
IgF3r8zRWq8kQoJlYMugmhsld0r0EsUJbsrcjBJ5CJ1WYZg1Vu8FpYLKoaFRI/qx
T6xCMvd238Q99Sdl6G6O9sQQoFq10EaYBa970Tl3nDziQQ6bbSNkZoOYIZoicx4+
1XFsrGiru8o8QIyc3g0eSgrd3esbUkuk0eH65SeaaOCrsaCOpJUqEziD+el4R6d4
0dTz/uxWmNpGKF4BmsNWeQi9b4gDYuFqNYhs7bnahvkK6LvtDThV79395px/oUz5
BEDdVwjxPJzgaAuUHE+6A1dMapkjsQIDAQABo3QwcjAOBgNVHQ8BAf8EBAMCBsAw
DAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBRqfIoPnXAOHNpfLaA8Jl+I6BW/nDAS
BgNVHSAECzAJMAcGBSoDBAUKMB0GA1UdDgQWBBT7j90x8xG2Sg2p7dCiEpsq3mo5
PTANBgkqhkiG9w0BAQsFAAOCAQEAaKEIpRJvhXcN3MvP7MIMzzuKh2O8kRVRQAoK
Cj0K0R9tTUFS5Ang1fEGMxIfLBohOlRhXgKtqJuB33IKzjyA/1IBuRUg2bEyecBf
45IohG+vn4fAHWTJcwVChHWcOUH+Uv1g7NX593nugv0fFdPqt0JCnsFx2c/r9oym
+VPP7p04BbXzYUk+17qmFBP/yNlltjzfeVnIOk4HauR9i94FrfynuZLuItB6ySCV
mOlfA0r1pHv5sofBEirhwceIw1EtFqEDstI+7XZMXgDwSRYFc1pTjrWMaua2Uktm
JyWZPfIY69pi/z4u+uAnlPuQZnksaGdZiIcAyrt5IXpNCU5wyg==
-----END CERTIFICATE-----
Until 2020-07-12

2LQIrINOzwWAVDhoYybqUcXXmVs

-----BEGIN CERTIFICATE-----
MIIEETCCAvmgAwIBAgIUf/dquk5/rxf1bf1oKN3DK/dldfAwDQYJKoZIhvcNAQEL
BQAwgYMxCzAJBgNVBAYTAlNFMRIwEAYDVQQHEwlTdG9ja2hvbG0xFDASBgNVBGET
CzU1OTExMC00ODA2MR0wGwYDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjENMAsG
A1UECxMEVGVzdDEcMBoGA1UEAxMTUlNBIFRFU1QgSXNzdWluZyBDQTAeFw0yMDA1
MTMxMzUxNTJaFw0yMzA1MTMxMzUxNTJaMIGKMQswCQYDVQQGEwJTRTESMBAGA1UE
BxMJU3RvY2tob2xtMRQwEgYDVQRhEws1NTkxMTAtNDgwNjEdMBsGA1UEChMUVmVy
aXNlYyBGcmVqYSBlSUQgQUIxDTALBgNVBAsTBFRlc3QxIzAhBgNVBAMTGkZyZWph
IGVJRCBURVNUIE9yZyBTaWduaW5nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAgMINs87TiouDPSSmpn05kZv9TN8XdopcHnElp6ElJLpQh3oYGIL4B71o
IgF3r8zRWq8kQoJlYMugmhsld0r0EsUJbsrcjBJ5CJ1WYZg1Vu8FpYLKoaFRI/qx
T6xCMvd238Q99Sdl6G6O9sQQoFq10EaYBa970Tl3nDziQQ6bbSNkZoOYIZoicx4+
1XFsrGiru8o8QIyc3g0eSgrd3esbUkuk0eH65SeaaOCrsaCOpJUqEziD+el4R6d4
0dTz/uxWmNpGKF4BmsNWeQi9b4gDYuFqNYhs7bnahvkK6LvtDThV79395px/oUz5
BEDdVwjxPJzgaAuUHE+6A1dMapkjsQIDAQABo3QwcjAOBgNVHQ8BAf8EBAMCBsAw
DAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBRqfIoPnXAOHNpfLaA8Jl+I6BW/nDAS
BgNVHSAECzAJMAcGBSoDBAUKMB0GA1UdDgQWBBT7j90x8xG2Sg2p7dCiEpsq3mo5
PTANBgkqhkiG9w0BAQsFAAOCAQEArir0lrtYRqxqPc3GmyL09tQEPcVGd/VuKMaj
JqoB6v219Ky/7atRaMdmY3NVHoGFY2gf2EB0MU2dGMuIbjYlC7EBi7T/ByIUJbKj
9gK5qUNtgHvOaTT0RFfGlCT45JTyCWMWZEM03DMXEvFMqqqJVXSyE212WfgbuZ9R
XVVT3BMJ23WY4wZp2Qi4NwUUjUNHf6EQKlrFuX9YjIGI0+JEITvQ3t20sU1yZt7x
EHOxZQ7gsgXydG/daFPsz08KJ+XH0i3vsRerh/lfodvBISudPeoUNkSPzd10KJRs
9OVsgi20aG7liHTRAtY8QSkV+973QUdw6EorceX6RG2AGlhljQ==
-----END CERTIFICATE-----
From 2020-05-13
DiZbzBfysUm6-IwI-GtienEsbjc-----BEGIN CERTIFICATE-----


MIID+zCCAuOgAwIBAgIUXB3gwjUzjQcd77CDrCgXXbeQPowwDQYJKoZIhvcNAQEL


BQAwgYMxCzAJBgNVBAYTAlNFMRIwEAYDVQQHEwlTdG9ja2hvbG0xFDASBgNVBGET


CzU1OTExMC00ODA2MR0wGwYDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjENMAsG


A1UECxMEVGVzdDEcMBoGA1UEAxMTUlNBIFRFU1QgSXNzdWluZyBDQTAeFw0yMzAy


MjMxMTQ4MThaFw0yNjAyMjMxMTQ4MThaMHUxIzAhBgNVBAMTGkZyZWphIGVJRCBU


RVNUIEpXUyBTaWduaW5nMRQwEgYDVQRhEws1NTkxMTAtNDgwNjENMAsGA1UECxME


VGVzdDEcMBoGA1UEChMTRnJlamEgZUlEIFN3ZWRlbiBBQjELMAkGA1UEBhMCU0Uw


ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiMthhWkZT9Ovye8qzJpL/


jHQODkVUUvQTvrE7uhG8rLKfya125XzIqfCAltazpfHS8e4o1cfET9PJ1YgsMlcE


UszMpgvDbBeBm28LipFUk1njXTtGV39+lQ88KLpTHKhRPRxEdmRpcMuX1tHD13a3


N0jwhcAWrFuZLsiheP1i7xNKda2Rontsg3prFPtzY4sW9kO1UQfOecay/MqIpGbs


uH7kQbIDrY18Z1TNX8YRc5E+K69gZTBl+pLjjpZy49P02HriKA3a8upU0QKSqio8


X1pkllBpXiIjib+Hxoze6xqnHfi3iHXidNjtxsam8b+gwwafKpSCFfl/rswTpPNR


AgMBAAGjdDByMA4GA1UdDwEB/wQEAwIGwDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQY


MBaAFGp8ig+dcA4c2l8toDwmX4joFb+cMBIGA1UdIAQLMAkwBwYFKgMEBQowHQYD


VR0OBBYEFL10m8p9GIWlWojIKxoXROpmkDdfMA0GCSqGSIb3DQEBCwUAA4IBAQAU


YsxIpDi7iju0yvupfhrGDyJk8AX7aDmhpyYWx+EitDHqI9aqULH+9GxEFRCor+Y2


a0d7hzkRzSITma0bvS+evpd4QwIhRRf00RASqnY4g4J+8knFoT7AJ7r2oJpogrzR


8L7e5BJUnnDA9btBh01Jq5Rh4aY3azRHFeS9E26/NaRbZhOaE23r8EDGGt1oYGOA


DkC2ouiJgnELga7DnYjroCDXRfzTeb2lmQzjyAp+tjW1MO1fQuN5cElyJkxDRtAS


0TTGXdXux9UDCFjJL+ZaMJxOFdX9i2gQTlMitY8FzQ10pFiGt77h93TQjTS/Sfz1


K2wpZ6CXk/WQQs1aXOl7


-----END CERTIFICATE-----
From 2023-02-23

JWS certificates in production

Production JWS certificate x5t Production JWS certificateFrom/Until

onjnxVgI3oUzWQMLciD7sQZ4mqM

-----BEGIN CERTIFICATE-----
MIIEvTCCAyWgAwIBAgIUZBsJTBnWAwJ2kWEgFlvLkadSONAwDQYJKoZIhvcNAQEL
BQAweTELMAkGA1UEBhMCU0UxFDASBgNVBGETCzU1OTExMC00ODA2MR0wGwYDVQQK
ExRWZXJpc2VjIEZyZWphIGVJRCBBQjETMBEGA1UECxMKUHJvZHVjdGlvbjEgMB4G
A1UEAxMXRnJlamEgZUlEIElzc3VpbmcgQ0EgdjEwHhcNMTcwODAyMTYyODIzWhcN
MjAwODAyMTYyODIzWjB6MSEwHwYDVQQDExhGcmVqYSBlSUQgSldTIFNpZ25pbmcg
djExFDASBgNVBGETCzU1OTExMC00ODA2MRMwEQYDVQQLEwpQcm9kdWN0aW9uMR0w
GwYDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjELMAkGA1UEBhMCU0UwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7y2YjMYwNq5j09dQQp293NdBskxEL
puPUEYE6DD0m3HvWZq3bJqaVuav9NSSXqevtuBm0BUpEFFDARief6bgozJY+WGkP
tURLjCoroHbkjA9jeX6Z1BpFdi/zOOlg4i19u0QxznBTTes41UT5uFwIrS2yq867
o8kczUs6RCGdw30Ikysm3t/zWWjHu6y4BTkMWvxLMQZFpuAad/vEjG+y0/+3oxzl
3CH9HhwQtT4xPH3UpcFw4nKt6hTXQDNSQUEQTQbB86Z6sAEPxwnvL/SZS7cmARw6
CeDX+fvJv6sXwBjsNGL7B3YMib/1rBPKE2jskqMrF1hYuqRd/xi1jjFRAgMBAAGj
gbswgbgwDgYDVR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwWAYIKwYBBQUHAQEE
TDBKMEgGCCsGAQUFBzAChjxodHRwczovL3d3dy5mcmVqYWVpZC5jb20vdGMvY2Vy
dHMvZnJlamFlaWRfaXNzdWluZ19jYV92MS5jZXIwHwYDVR0jBBgwFoAUED8kN9o6
iEfwKOPN0xXwS6n2sVAwHQYDVR0OBBYEFJJt+ukaSQCnRFQpuEVrwG9c2EDNMA0G
CSqGSIb3DQEBCwUAA4IBgQAZiytgukQ4ka0VXnkDbtEiF8LluPz3pFIZrXJTllmF
EGYT3RSb4e52wKkEzPZG0z0JlpjeZHeU8LOyKDe3jqDMSc7N0t5mA25GgjNOGYme
JZYsFlZZrP6jmNTSfFJKpy3Uvoj7+CKt+0qei4CB/RPscRrGHDMyc8lLVH6Bh1oI
9NRMB1m23AWFEXEKtQJUMTBOcMVcUaHm2jjZvagLf/SJ+jU1VFc/OzJYud8IAL6J
EfWn4deY5qUEJTQrLskF2jyL/5VTHJsk8DC90wjt0lJFX7nKS/MqCr+0yEIHIwST
APa/7M16YKBkEdQidcu2uYp4GHZCcB72XDxXO8JtL62OPTS80HgA9kMb5MZdJeo2
awGyCBVPbZXAgfypr6pGQafMFkZoBzp9N1z+YGEJqEAFgljS5vNtEUGsPiRe8DUP
A59tnAEF09W7HQDw3hSabyYNGuMndtV575CvyXFBOH4VM6bda+MC+8oy0SyubD/h
daqqd+KNF8QMZrDM6RqcWao=
-----END CERTIFICATE-----
Until 2020-08-02

aRw9OLn2BhM7hxoc458cIXHfezw

-----BEGIN CERTIFICATE-----
MIIEvTCCAyWgAwIBAgIUHOOkesGZPQnJ2w/tfx3ia9LQR1swDQYJKoZIhvcNAQEL
BQAweTELMAkGA1UEBhMCU0UxFDASBgNVBGETCzU1OTExMC00ODA2MR0wGwYDVQQK
ExRWZXJpc2VjIEZyZWphIGVJRCBBQjETMBEGA1UECxMKUHJvZHVjdGlvbjEgMB4G
A1UEAxMXRnJlamEgZUlEIElzc3VpbmcgQ0EgdjEwHhcNMjAwNTE0MDkxODU1WhcN
MjMwNTE0MDkxODU1WjB6MSEwHwYDVQQDExhGcmVqYSBlSUQgSldTIFNpZ25pbmcg
djIxFDASBgNVBGETCzU1OTExMC00ODA2MRMwEQYDVQQLEwpQcm9kdWN0aW9uMR0w
GwYDVQQKExRWZXJpc2VjIEZyZWphIGVJRCBBQjELMAkGA1UEBhMCU0UwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1b0Napazk5UxsaV5aO82d1ab6wXMO
ci+Tvv08sIGx8PXYYOvA1GRsJy+l5hDjbdzhk3ftrlx1gq7WmRhFgFuwP8ZHAWIq
OF/JQQtKUEPrUbMulqJyMyAvb+tpGyBNTHpvOSIvcazTq9jdDkKQ5xuaGpVdE3dh
8og2bJbKbXBlSuBxB85L5IxZvkQJ8Fs40rLVN58p3ppX36d5aHVLBp+7f1hRGpI9
KTKoeH5RVtF/BaVLNWnKZ5WEiG5G4tbzc6H06UeUFu/XGXTl3ji7Kd5w5/aSFP1+
XF0ntRtdJkCvPI/eYEF8KDsJR9V1wOn+Wje/J2YLZ33giD+HLUbZfNBxAgMBAAGj
gbswgbgwDgYDVR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwWAYIKwYBBQUHAQEE
TDBKMEgGCCsGAQUFBzAChjxodHRwczovL3d3dy5mcmVqYWVpZC5jb20vdGMvY2Vy
dHMvZnJlamFlaWRfaXNzdWluZ19jYV92MS5jZXIwHwYDVR0jBBgwFoAUED8kN9o6
iEfwKOPN0xXwS6n2sVAwHQYDVR0OBBYEFLPEmwpnlugc7/DRNhyS4Uaw3d/PMA0G
CSqGSIb3DQEBCwUAA4IBgQAn4coTJBL7PUQhpRVNbGyigWIyOfumxkiIU1GumLqe
G/8z0C0JI4OV5olFOVm0xjGW2WkdMq5vZVTZCfur7L/ftQ06C5tyE2IubWOdUVFp
IL3ephlFYCTVzOCZuh2fRmL8XzuyGCNauQh5r4UsxwGh8Gh039uf77ZprcsnbsIg
XgvkT1fuvB/VoUGJ6OrLWAd+U0i7DHBWkh+siGZiiE1xaaMDjnXa7+3ks0W2Ukwa
tt+Jj+zCcmGP/R0luhsPM/RWC5ARQq2zWCzoU7dRyhlX1qPEecDId7vTT+8umaMc
jYt9L1+D1botwUOX/y7V49eOKulGOGlBCsrwxnE4tt+29k26UPGoxvdwleifFx4g
dh9QjbwKjqXnZ6oip9r76yjP7pASgqWtcTdKQV9Cav66W6Ta21oxgNRq2S8xSeiS
DR7uXDX7RqAEjd0k3tCUxXwVMH6WorUQA+NszpR5hr0lTRYALTsTSj8VdgFJDam0
vsYzHH84bfb942CcNv9bbOA=
-----END CERTIFICATE-----
From 2020-05-14
wSYLdhe93ToPR2X1UrNXxOg1juI-----BEGIN CERTIFICATE-----


MIIEvDCCAySgAwIBAgIUO7H1JLQMSMERte/IgsBUOP6qBSYwDQYJKoZIhvcNAQEL
BQAweTELMAkGA1UEBhMCU0UxFDASBgNVBGETCzU1OTExMC00ODA2MR0wGwYDVQQK


ExRWZXJpc2VjIEZyZWphIGVJRCBBQjETMBEGA1UECxMKUHJvZHVjdGlvbjEgMB4G


A1UEAxMXRnJlamEgZUlEIElzc3VpbmcgQ0EgdjEwHhcNMjMwMjIzMTI1NDI5WhcN


MjYwMjIzMTI1NDI5WjB5MSEwHwYDVQQDExhGcmVqYSBlSUQgSldTIFNpZ25pbmcg


djMxFDASBgNVBGETCzU1OTExMC00ODA2MRMwEQYDVQQLEwpQcm9kdWN0aW9uMRww


GgYDVQQKExNGcmVqYSBlSUQgU3dlZGVuIEFCMQswCQYDVQQGEwJTRTCCASIwDQYJ


KoZIhvcNAQEBBQADggEPADCCAQoCggEBALBpp0UVzAVmZFiTVxhdJcAwkAt6hUmn


JVi9uddgMUQLQnKNa6ip3np3iOydHcq627LENg9PIBVyRy/CjMoLQ2eiOQi7r4hs


cJPBECYuBwQJEPxeMuP2b4BTk1dh2w1HDD4ZijRV4bbo8E4H39EbZvvBPaB1C7BK


wVGJmV471A+5MpvgkSMisROz9xtqhVKy94+zYValv6mYq90X42L489aOEu8wY1N+


VvzFH5CGZpgY9ttulfT4ykfstDZE4qKXnN4VAJlEU9PKnE+8HlGK15S8Mo9rwE80


lklPnZPSMuiBztpZkYy4ug4cBu2ZTwxydu5J6PfdJMfnk+JaCjgc8bMCAwEAAaOB


uzCBuDAOBgNVHQ8BAf8EBAMCBsAwDAYDVR0TAQH/BAIwADBYBggrBgEFBQcBAQRM


MEowSAYIKwYBBQUHMAKGPGh0dHBzOi8vd3d3LmZyZWphZWlkLmNvbS90Yy9jZXJ0


cy9mcmVqYWVpZF9pc3N1aW5nX2NhX3YxLmNlcjAfBgNVHSMEGDAWgBQQPyQ32jqI


R/Ao483TFfBLqfaxUDAdBgNVHQ4EFgQUAIg4CkKACFOmRUmry1/9Pb48No0wDQYJ


KoZIhvcNAQELBQADggGBAH/lokazs32mk5QlUYTZBkoP5IOxuYbm8pbr/pgDfz/E


NEJ8OWycfDuS/fBBL59OwjOfWBlmFdDtUXoTYCjYjNVrIvfNOE62dAXN4RzqBq+c


Uoov6MDvYfARi1B3wWuAwbZ2swNRuh/NyNLB3RsfHXya/XjA3w2MYfIeytKdBvcS


LMOiwx4wxePtox8OuL0H6wAA8mmJdW0lCPyAyYiRRmP91DpLQwpXGCgN6MLJwpAA


t611z17VoZhYT6PaSHvhyV05q3o/ayRFAp2xTh7ZoAALsBcEeaSg27RuuxxHFDeW


6aqsZiUbkqEdBvaUcbN7s33O1gTLnPLhsTjMTtjwKfLCd+1jR32MQw1WdXXpgZRF


pIgy5DW9jrOeFGUOfc+wErAeykm+XlrsBC/I3/mRra1fLYnvLToTkHPfWl1jQYfA


E38EAlxcQpaV46znmReHq/xB+/yTWLboJO/UMgp8PyqCiumP4kXu7oLJ++48R+nu


kptNjrjW1RSy4YOYySFxuA==


-----END CERTIFICATE-----
From 2023-02-23

General information about Freja eID RESTful APIs

Authentication and Signature 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 OKSuccess, additional information is available in the body.
204 No ContentSuccess, no additional information is available in the body.
400 Bad RequestThe request is malformed. For example, the body cannot be parsed.
404 Not FoundRequested resource does not exist.
410 GoneRequested resource is no longer available. For example, an obsolete API version.
422 Unprocessable EntityValidation or processing errors. Additional information is available in the body. If the input is corrected, the request can be resubmitted.
500 Internal server errorThe 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"
} 


Tip
iconfalse

Go to: