Technical Agreements

Technical Agreements

This developer portal provides a full overview of the current state of the iSHARE Scheme’s (v1.9) technical agreements, and of how these agreements are applied.

iSHARE is a collaborative effort to improve conditions for data-sharing for organisations involved in the logistics sector. The iSHARE Scheme focuses on the topics of identification, authentication and authorisation.

This page describes the iSHARE standards & specifications for Identification, Authentication and Authorisation. Both for machine2machine and human2machine interaction. At the end, an alphabetical overview is given of all technical concepts and how they are applied in iSHARE.

Not much of a reader?
Start off by checking the iSHARE API specs, or start testing against the iSHARE mock APIs right away
Very much of a reader?
Make sure to check out the entire iSHARE Scheme of agreements 
Version: 1.9

iSHARE JWT

iSHARE use of JSON Web Token (JWT)

A JSON Web Token (JWT) is used when non-repudiation between parties is required. A statement, of which the data is encoded in JSON, is digitally signed to protect the authenticity and integrity of the statement.

iSHARE uses signed JWTs in the following ways:

  1. In a request for an OAuth Access Token or an OpenID Connect ID token the client sends a signed JWT. The client is authenticated based on the verification of the JWT's signature.
  2. Delegation evidence is presented as a signed JWT. The signature of the Authorization Registry or Entitled Party provides proof to other parties.
  3. In a response from a server iSHARE metadata is presented as a signed JWT. The signature is used to bind the iSHARE metadata (such as license information) in the JWT to the content of the response.
  4. A service from an iSHARE Service Provider MAY require a request to be signed.
  5. If there is potential that a JWT could be intercepted by intermediaries, JSON Web Encryption (JWE) may be used. This is explicitly used in Human2Machine interaction in the OpenID flow.

The following section describes the requirements for an iSHARE Signed JWT.

JWT Signing

All iSHARE JWTs MUST be signed using the JWS specifications.

JWT Header

For the header of an iSHARE signed JWT the following requirements apply:

  • Signed JWTs MUST use and specify the RS256 algorithm in the alg header parameter
  • Signed JWTs MUST contain an array of the complete certificate chain that should be used for validating the JWT's signature in the x5c header parameter up until an Issuing CA is listed from the iSHARE Trusted List (regarding the eIDAS Framework, with all individual CAs listed on the Trusted List, it is expected that this x5c Header only contains the client's certificate)
  • Certificates MUST be formatted as base64 encoded DER
  • The certificate of the client MUST be the first in the array, the root certificate MUST be the last
  • Except from the alg, typ and x5c parameter, the JWT header SHALL NOT contain other header parameters
Example JWT Header
{
  "alg": "RS256",
  "typ": "JWT",
  "x5c": ["MIIGCDCCA/CgAwIBAgICEAQwDQYJKoZIhvcNAQELBQAwgZAxCzAJBgNVBAYTAk5MMQswCQYDVQQIDAJOSDEPMA0GA1UECgwGaVNIQVJFMREwDwYDVQQLDAhTZWN1cml0eTEoMCYGA1UEAwwfaVNIQVJFIE5MIENlcnRpZmljYXRlIEF1dGhvcml0eTEmMCQGCSqGSIb3DQEJARYXaW5mb0Bpc2hhcmUtcHJvamVjdC5vcmcwHhcNMTcwNjI3MDgyOTIzWhcNMTgwNzA3MDgyOTIzWjCBnDELMAkGA1UEBhMCTkwxCzAJBgNVBAgMAk5IMRIwEAYDVQQHDAlBbXN0ZXJkYW0xDzANBgNVBAoMBmlTSEFSRTERMA8GA1UECwwIU2VjdXJpdHkxIDAeBgNVBAMMF2lTSEFSRSBTY2hlbWUgT3duZXIgUE9DMSYwJAYJKoZIhvcNAQkBFhdpbmZvQGlzaGFyZS1wcm9qZWN0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALp1Yk0cu6U7M13mcQupWj+TADy/hwEHWmmGGFFRaLMURuujDsKCHeu89Lvq71QQWkxxJWAHP6oRe3UCzCdMjXh6PoEQnnyC3dUgX3pGjQG1oT0a7tyMdMWzAW92MJW2BF8P7ZRMlDskf7BJh1QPrF/p53+S0uexZNNSB3/ZZjLpantIL3iF9mxPKBJX2c5dY666rt3+fadLhGf0AtG950M6BV3GmMNbx8sNQV+hCQ0OeIirhkIi+08ovcHTE7DP7+3BB2edDoCgSXStLHrodB8wZBBGLBgm7tqcDz5pkaDetIrsYKNXQqERFjU2TYurBlnll64pce/SOUiy+KDxhjcCAwEAAaOCAVwwggFYMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBTZXJ2ZXIgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFBEdKZ61hpM+ZDLNWLKlbxbBlIVoMIG+BgNVHSMEgbYwgbOAFI5GTdMUiapXImVUi9T21ZsCN9zroYGWpIGTMIGQMQswCQYDVQQGEwJOTDELMAkGA1UECAwCTkgxEjAQBgNVBAcMCUFtc3RlcmRhbTEPMA0GA1UECgwGaVNIQVJFMREwDwYDVQQLDAhTZWN1cml0eTEUMBIGA1UEAwwLaVNIQVJFIFJvb3QxJjAkBgkqhkiG9w0BCQEWF2luZm9AaXNoYXJlLXByb2plY3Qub3JnggIQADAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggIBAANm0QHtsbfkVqxr6jJgtDvvIGQqmuryMpue1Log6HZZ2QowZWrG8o/4SAglpMPTuVU0UfABk5dVfOXnmBa5lRMI7hl9dSM1HNle6C9WA7RQtNV/v4qBe0OlgfaD4cUAJDkHsIwWSMlcelOoxVZNcdOwadXAQHgYduzBSdR8/Ps3plvIDIE9lrGt7GkUzxS3WU1XVss6nKZFWlZktqQH5Y+WEG//60+1Wf4aI6VHIuoRj10/NlEvjct0Zx0yiZU2RrqwPqsrtBYbCPIuO+Cl9QM73pHY3zYqkWY4CLaewvyPZaY5KDBh7nZOp9NJ1Z2XWFuVIDTZReH2ARXFpkWDaHmhAcMZ9BiqM+hx4IXeC68Vvwua+guypPJZfRyE33sox/lu8ecL2L7/ehDgji8IESymUPI32CpKfMN1KKNL/KEtftGPpuV+6iQNTE4hTCBcBaSf3dxsGHclOSC6Ke9tL4YRLiX3+YsHqYD98vLRRObIQZGWXiqvSFsLCwK0M1RIwsfb6B9S+XMRAiwr1iezBdHxXaH81lT+WxJfnDun6uxXUz4xTuzaVXsV0gvcY3quYp64LR6Rrhnc2DkNDzZU6JHyF7LX70rn8Lj180jjG1ge6ll9DLPQTkVyShTqCUV+9wrU2aE16rqe2YAq/lLJ0dWOHS2pJcQjh1iDpAqGObwT"]
}

JWT Payload

For the payload of an iSHARE signed JWT the following requirements apply:

  • The JWT payload MUST conform to the private_key_jwt method as specified in OpenID Connect 1.0 Chapter 9
  • The JWT MUST always contain the iat claim
  • The iss and sub claims MUST contain the valid iSHARE identifier of the client
  • The aud claim MUST contain only the valid iSHARE identifier of the server. (Including multiple audiences creates a risk of impersonation and is therefore not allowed)
  • The JWT MUST be set to expire in 30 seconds. The combination of iat and exp claims MUST reflect that. Both iat and exp MUST be in seconds, NOT milliseconds. See UTC Time formatting for requirements
  • The JWT MUST contain the jti claim for audit trail purposes. The jti is not necessary a GUID
  • Depending on the use of the JWT other JWT payload data MAY be defined
Additional rationale
  1. In OAuth 2.0 clients are generally pre-registered. Since in iSHARE servers interact with clients that have been previously unknown this is not a workable requirement. Therefore iSHARE implements a generic client identification and authentication scheme, based on iSHARE whitelisted PKIs.
  2. Since OAuth 2.0 doesn't specify a PKI based authentication scheme, but OpenID Connect 1.0 does, iSHARE chooses to use the scheme specified by OpenID Connect in all use cases. This is preferred above defining a new proprietary scheme.
Example JWT Payload
{
  "iss": "EU.EORI.NL123456789",
  "sub": "EU.EORI.NL123456789",
  "aud": "EU.EORI.NL987654321",
  "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59",
  "exp": 1504683475,
  "iat": 1504683445
}

JWT Processing

  • A server SHALL NOT accept a JWT more than once for authentication of the Client. However within it's time to live a Service Provider MAY forward a JWT from a Service Consumer to one or more other servers (Entitled Party or Authorization Registry) to obtain additional evidence on behalf of the Service Consumer. These other servers SHALL accept the JWT for indirect authentication of the Service Consumer during the JWT's complete time to live
  • A server SHALL only accept a forwarded JWT if the aud claim of the forwarded JWT matches the iss claim of the JWT from the client that forwards the JWT
  • JWT contents that are not specified within the iSHARE scope SHOULD be ignored

JSON Web Encryption

  • JSON Web Encryption (JWE) is used to encrypt the JWS when there is the potential that a JWS could be intercepted by intermediaries. Since a JWS only encodes and signs information, it supports non-repudiation. It is assumed that communication within iSHARE is done over a TLS encrypted line (which is mandatory per the OAuth specification). In case of direct machine to machine use cases, this is secure enough to prevent interception between intermediaries.
  • In cases where the actual data transfer is done using some other transport protocol (other than HTTPS using TLS), an encoded JWS would not protect data from being read as long as it is intercepted in between. To make sure that such data in JWS is also secure and only the intended party can open it, we prescribe to use the JWE specification for encrypting JWS. The specification can be found in RFC7516.
  • In human to machine cases using OpenID, the initial flow requires a Service Provider to send the request JWS to the User Agent for redirection to the Identity Provider. In such a case, a JWS can be easily intercepted and read by the user. Using JWE, the contents of the JWS can be encrypted in such a case.
  • When Identity Brokers are used within iSHARE, it would be necessary to encrypt the JWS to make sure data is not unnecessarily readable by the Identity Broker.
  • Apart from the case in the human to machine flow, when data is exchanged, it may be needed to be encrypted (aside from TLS) for various reasons. JWE could be used in those cases.

iSHARE Authentication

Authentication description

iSHARE uses the OAuth 2.0 protocol for authenticating parties and providing access tokens when requesting access to a service within iSHARE. For the most recent version of the OAuth 2.0 specification click on this link.

This section describes how iSHARE uses the OAuth authentication framework for authenticating organisation based on the iSHARE agreements.

In addition to the OAuth 2.0 specifications, the following requirements apply for iSHARE:

  • Clients MUST NOT be pre registered. A look-up in the iSHARE adherence registry is sufficient. It is up to the server create a new entry for Clients that perform requests for the first time
  • The client_id MUST contain the valid iSHARE identifier of the client
  • For interoperability reasons clients SHOULD only make HTTP GET calls to the /oauth2.0/token endpoint. However, in case of potential HTTP message size restrictions on the server, a POST call alternative MUST be offered
  • Servers SHALL NOT issue refresh tokens
Additional rationale

In OAuth 2.0 clients are generally pre-registered. Since in iSHARE servers interact with clients that have been previously unknown this is not a workable requirement. Therefore iSHARE implements a generic client identification and authentication scheme, based on iSHARE whitelisted PKIs.

Generic authentication flow

Based on the described standards and specifications in this scheme, the generic iSHARE Authentication flow is described in the following sequence diagram.

For a deeper understanding of the various roles within the iSHARE Trust network, take a look at the 'Framework and roles' page in the official iSHARE Scheme of agreements.

Additional information on flow
The sequence diagram refers to Service Consumer, Service Provider and Scheme Owner. Please note that this Authentication flow applies to various possible interactions. Each party that needs to authenticate another party requesting data or services can be authenticated through this flow.

OAuth2.0 access token

Used to obtain an OAuth access token from a party that exposes an iSHARE API. Based on the requirements in the OAuth 2.0 Authorization framework

This API request displays what is required to obtain an access token

POST /oauth2.0/token

The above endpoint is not specific. For example, some OAuth libraries have a fixed endpoint of /connect/token.

Default is a HTTP POST request.

grant_type
in formData
string

OAuth 2.0 grant type. MUST contain "client_credentials"

scope
in formData
string

OAuth 2.0 scope. Defaults to "iSHARE", indicating all rights of the Service Consumer are requested. Other values allow the Service Consumer to get tokens that do not include all rights the Service Consumer has.

client_id
in formData
string

OpenID Connect 1.0 client ID. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain a valid iSHARE identifier of the Service Consumer

client_assertion_type
in formData
string

OpenID Connect 1.0 client assertion type. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain "urn:ietf:params:oauth:client-assertion-type:jwt-bearer"

client_assertion
in formData
string

OpenID Connect 1.0 client assertion. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain JWT token conform iSHARE specifications, signed by the client.

Request body Example application/x-www-form-urlencoded
grant_type=client_credentials&scope=iSHARE&client_id=EU.EORI.NL000000003&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlFZ3pDQ0FtdWdBd0lCQWdJSWFkL3BJSExySmlNd0RRWUpLb1pJaHZjTkFRRUxCUUF3U0RFWk1CY0dBMVVFQXd3UWFWTklRVkpGVkdWemRFTkJYMVJNVXpFTk1Bc0dBMVVFQ3d3RVZHVnpkREVQTUEwR0ExVUVDZ3dHYVZOSVFWSkZNUXN3Q1FZRFZRUUdFd0pPVERBZUZ3MHhPREEzTWpVeE5UQXhORE5hRncweU1EQTNNalF4TlRBeE5ETmFNRG94RlRBVEJnTlZCQU1NREZkaGNtVm9iM1Z6WlNBeE16RVVNQklHQTFVRUJSTUxUa3d3TURBd01EQXdNRE14Q3pBSkJnTlZCQVlUQWs1TU1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBMk1PWG9BN1lwNHFBMGp6K0E0Sm5jWmlBa0ZJc2w3T0xVRW4rV0JEczVhTzFjeXFqZ0FIMFk2SnJBMDIyZXJMUlFxK1BNM04zT0JXUVErb05Ubnl0cTVIK0cvaklKVXkvRUFsRHoxNHIxMWNycm5GNHJ2M25lbmtTUDRjenFueDhRc3laUGVCMUk1UnJCZWd4WVhYVmdFeTJyL3hnVTlzaUdDOVdQVUxQUXllSnhwZWU2Y3Y4cDYxRVhlL1BJako0TVRVa2g5STV2Z0Zxb3hJZnE0b0RCck9CRktQSkxlNGhXdEdWTDk4MVZDRXlKRnQ0K3V4NFFwNlNuS1VTZzJZQXJmQldGdVB4R3RxTTBaK1h2K0tVaUc4ZCtMRlhabnNjOFpCZlFnajIvQkErQS9XTU5qTHFKRDZSTEpQcUhkUlZycmh6TlZ3ZTdpSnowL0xiWlJvZXhRSURBUUFCbzM4d2ZUQU1CZ05WSFJNQkFmOEVBakFBTUI4R0ExVWRJd1FZTUJhQUZCWTg1eURwMXBUdkgrV2k4Ymo4dnVyZkxEZUJNQjBHQTFVZEpRUVdNQlFHQ0NzR0FRVUZCd01DQmdnckJnRUZCUWNEQkRBZEJnTlZIUTRFRmdRVUd6UmlXdXArVWtab1dTUTcyTVlvTzNDYzhPa3dEZ1lEVlIwUEFRSC9CQVFEQWdYZ01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQVlxeTZDZTFKWkNETU1FRmM1b0JEamRyNWhaWXBMMFUzNi8xVk94SkNvbFp6eTVZYWtBT0FjdnVKcHFkNTVsT3F6aU5DbFpYYWpCUXhYaVlqZTZxNlVJU09McW9BckVmVy93NmlDa2NtVERYcTFlQ200SHNJNkdibVJ0UklBMTdxNWE4T3dwZFg3MlVUZFRKOXY1Rmw0OVlrdHM3OTY0cHJuNHJrbW0rRDZkQTBRbDBCQ0FIOHU2ZnQxQ0xWNDdIQStNL3J6eXVCLy9ZZENaQ0I1Ung3V0lsTXNCSGtkam9acWVmYlJVaEthOFFoa1NuOUgybWV5N2Vsa3Qxd1ZyRjdXVVlRWUZhd01sSHBrSUhFZjFtcUhIcWg4Y2J2N3g3Sy9Wdk4zVXAra1p5M2M0M2VXRlUyUDB0UnpFMGpZbXhLZDNsaE5DRFprcmdLajQ3aVVyZXc3bXFIdnVpYnVLNTc4UCtwY2lWenBBTmw5aFNPckpxSUFaSlhJODcweUdsaFozMkJBQnRlWmU1SndSeGV5YzZCTG9RNCs2WndVM0VJcDljenkrRExRM28yU1Rmanc0WUFyaWk5c0s5bGJkRUZFQUlSK1QyZnBmN1ZrVGJQcHEzVXRVS0d5aWJ0Snh2Wnk1R25scTRWVnU5U1RiMGVhdU5vcXFTZnpqWjZqRVR4NjhGb3ZHbzVqZmNmZnlINnUvdlIvK2RhNFBzeTZncmM5Y2N5TjlHZ2phYjNhWDE2MStyeTR1enhXTS9kOWI0RWxoVmk4U3FWZ3hpRmlEQ0xQamlZYllxRHlTcTZZRE5teTlKSnNxQ3RVYlNzV3UvRFl0Nm1Kb3BpRXJROXNFMEphSk5STEd3cE1OUmV0QVk1cVlEVjI0c2NGS1dTQVM3b3ZXdVpWdDFVZUhnPT0iXX0.eyJpc3MiOiJFVS5FT1JJLk5MMDAwMDAwMDAzIiwic3ViIjoiRVUuRU9SSS5OTDAwMDAwMDAwMyIsImF1ZCI6WyJFVS5FT1JJLk5MMDAwMDAwMDAxIiwiaHR0cHM6Ly9pc2hhcmUtc28tcWEuYXp1cmV3ZWJzaXRlcy5uZXQvY29ubmVjdC90b2tlbiJdLCJqdGkiOiIyODFiYTU5ZmMyMTM0YmI5YWQ2YTI5Mjg5NGQyNDlkNyIsImlhdCI6IjE1Mzk2ODg5MjciLCJleHAiOjE1Mzk2ODg5NTcsIm5iZiI6MTUzOTY4ODkyN30.h3rIVNKqKDQZY2MI1IN2-1fjW0nDiVD3NYG9QfIxQ28-4RuAl1frYNVk2a3Lf7GWkJ5XrLAJavhBYW1O27tXz_RE4ssY2r3SDXNn-5IXuy3mrW2r1h91uJ8kXKs8kqTuSWK7WaWwW4zECPfmvfTHAod6RbAXSSDf9NEhb8wXC9LC3kZUxshuYfj1xQ2uMVfjyxhSJCpxSGpTtOH_ttjpknB8gufBbskq6uP3SXjLg7mhCuMTL5BprvU8fwp-TX5HzvXm1dRsN99aYi_gfzdxwplI2Y_XHxGHR7j7uJlTEU66sl3CnSFFHQq6Tk8jF5GQ2lqfuLeL2pdxDz2A0I_MeQ
200 OK
Response Example (200 OK)
{
  "access_token": "access_token",
  "token_type": "token_type",
  "expires_in": 0
}

Human2Machine interaction

Description

Besides Machine2Machine interaction, it can occur that it is relevant if a specific person requests data or a service. In order to provide a Service Provider with identity information on a human subject, iSHARE uses the OpenID Connect 1.0 protocol.

The iSHARE use of OpenID Connect 1.0 is based on the requirements from the official standard.

In addition to the OpenID Connect specifications, the following requirements apply:

  • Clients MUST NOT be pre registered. A look-up in the iSHARE adherence registry is sufficient. It is up to the server to create a new entry for Clients that perform requests for the first time
  • The client_id MUST contain the valid iSHARE identifier of the client
  • Servers SHALL NOT issue refresh tokens

Generic authentication flow

Based on the described standards and specifications in this scheme, the generic iSHARE Human2Machine Authentication flow is described in the following sequence diagram.

Additional information on flow
The sequence diagram shows how the Service Provider interacts with an Identity Provider in order to receive identity information on the human user (who uses a browser to interact with the Service Provider). The specific details of the steps in this authentication flow are described in the generic API documentation of iSHARE:
  1. /identity_provider/authorize
  2. /service_provider/openid_connect1.0/return
  3. /identity_provider/token
  4. /identity_provider/userinfo
A few remarks regarding this flow:
  • Human user might interact with Service Provider in a different way than using a web browser
  • After the Service Provider initiates a GET /token request, the Identity Provider can verify their iSHARE Adherence with the Scheme Owner. Adherence checks or certificate validation is not displayed in this flow as this flow only describes the generic OpenID Connect 1.0 flow
  • This flow only describes Identification & Authentication of a human user, while in iSHARE it is always relevant that their Authorisation (acting on behalf of an organisation) is also verified. This proces is described in the Human Authorisation section

Identity JWTs

The OpenID Connect 1.0 flow contains 2 important iSHARE-specific JWTs, which are described in more detail in this section.

"request" JWT /authorize request

In the /authorize request, a "request" parameter must be provided. This parameter is an iSHARE compliant JWT, with additional parameters within this token.

The request JWT contains the following additional parameters:

sub
in query
string

A URN specifying subject fo this authorization request. Since, Id or pseudonym of the user is not known upfront, an URN indicating that the currently authenticated user is the subject. In response, a pseudonym of the user MUST be returned by the Identity Provider.

response_type
in query
string

OAuth 2.0 Response Type. For iSHARE using the Authorization Code Flow, with value "code" is REQUIRED. MUST be identical to the response_type value in the query parameter of the /authorize request.

client_id
in query
string

OpenID Connect 1.0 client ID. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain a valid iSHARE identifier. MUST be identical to the client_id value in the query parameter of the /authorize request.

scope
in query
string

OAuth 2.0 scope for OpenID Connect 1.0. MUST contain the "openid" scope value and one or more scopes identifying the attributes from the Human Service Consumer that are requested. MUST be identical to the scope value in the query parameter of the /authorize request.

redirect_uri
in query
string

OpenID Connect 1.0 redirection URI to which the response will be sent. Note that by transporting the redirect_uri in a signed JWT, security considerations regarding un-pre-registered redirect_uri's are properly addressed.

state
in query
string

OpenID Connect 1.0 opaque value used to maintain state between the request and the callback. MUST be used in iSHARE.

nonce
in query
string

OpenID Connect 1.0 value used to associate a Client session with an ID Token. MUST be used in iSHARE.

language
in query
string

iSHARE specific two-letter indicator that guides the language of the user interface shown by the Identity Broke or Identity Provider.

Request JWT Payload Example
{
  "iss": "EU.EORI.NL123456789",
  "sub": "urn:TBD", //URN (TBD = to be determined)
 indicating the authenticated user's pseudonym  
  "aud": "EU.EORI.NL987654321",
  "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", //Note this is not necessary a GUID
  "exp": 1504683475,
  "iat": 1504683445
  "response_type": "code",
  "client_id": "EU.EORI.NL123456789",
  "scope": "openid name contact_details",
  "redirect_uri": "https://example.client.com/openid_connect1.0/return",
  "state": "af0ifjsldkj",
  "nonce": "c428224ca5a",
  "language": "nl"
}

"scope" parameter

In the /authorize request , the "scope" parameter MUST contain the "openid" scope value and one or more scopes identifying the attributes from the Human Service Consumer that are requested (depending on the OpenID implementation of the Identity Provider) and MAY also contain the "iSHARE" scope. The "iSHARE" scope contains the minimal information required for authorisations. The "scope" parameter MUST be identical to the scope value in the query parameter of the /authorize request.

"id_token" JWT /token response

In response to the /token request, an "id_token" is provided to the client (as an addition to the regular OAuth access token response). This id_token is an iSHARE compliant JWT, however the "sub" parameter is changed and additional parameters are added.

The id_token contains the changed "sub" parameter and the following additional parameters:

sub
in query
string

OpenID Connect 1.0 locally unique and never reassigned identifier within the Identity Provider for the Human Service Consumer, which is intended to be consumed by the client. (iSHARE human pseudonym).

auth_time
in query
string

OpenID Connect 1.0 time when the Human Service Consumer authentication occurred. Formatted in Unix timestamp format

nonce
in query
string

OpenID Connect 1.0 value used to associate a Client session with an ID Token. Contains value as passed in to the /openid_connect1.0/authorize endpoint. MUST be used in iSHARE.

acr
in query
string

OpenID Connect 1.0 authentication context class reference. MUST either contain urn:http://eidas.europa.eu/LoA/NotNotified/low, urn:http://eidas.europa.eu/LoA/NotNotified/substantial or urn:http://eidas.europa.eu/LoA/NotNotified/high, depending on the quality of the authentication method.

azp
in query
string

OpenID Connect 1.0 authorised party. MUST be identical to the client_id that requested the ID Token. Also identical to aud. MUST be used in iSHARE.

id_token Payload Example
{
  "iss": "EU.EORI.NL983748194", //Identity Provider EORI
  "sub": "419404e1-07ce-4d80-9e8a-eca94vde0003de", //Note this the human pseudonym
  "aud": "EU.EORI.NL123456789", //Service Provider EORI
  "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", //Note this is not necessary a GUID
  "exp": 1504683475,
  "iat": 1504683445,
  "auth_time": 1504683435,
  "nonce": "c428224ca5a",
  "acr": "urn:http://eidas.europa.eu/LoA/NotNotified/low", //level of assurance
  "azp": "EU.EORI.NLNL123456789", //Service Provider EORI, must be identical to client ID from the request
}  

Human pseudonym

An essential part of the Human2Machine flow is the pseudonym used to refer to humans without exposing their identity.

Pseudonyms are used to obscure the real identities of the human users for privacy issues. It's possible that a human user may be representing more than one organization, which the service provider may not need to know about. If such a user uses a single identity then he could be unwillingly giving away this possibly sensitive information.

Using pseudonyms, the user’s identities are not easily linked to each other. On the other hand, some use cases may require the user’s identities to be linkable to service the user better. In this case the use of pseudonym makes sense as a user could always link them together on his own will.

The following is a list of criteria for generating pseudonyms:

  • The generation of a pseudonym MUST be non predictable
  • The exact method of generating the pseudonym is left out to Identity Providers
  • The pseudonym MUST depend on the human user
  • The pseudonym MUST depend on the Identity Provider
  • The pseudonym MUST depend on the Service Provider

iSHARE Authorisation

Description

A core functionality of iSHARE is managing authorisations, either on an organisational level or on a personal level. Read more on the background of iSHARE Authorisations in the iSHARE Scheme.

Within iSHARE, participants can request so-called "delegation evidence" from either an Entitled Party or one of the Authorization Registries. In order to receive this evidence, various rules need to be followed:

  • An organisation can only request evidence for an Authorisation policy that concerns this organisation. The organisation is either the creater or "issuer" of the policy, or is the subject to which the policy applies
  • The only exception to the previous rule occurs when a Service Provider needs to gather delegation evidence on behalf of a client which is consuming his service. The Service Provider passes a valid "client_assertion" of this client to the Entitled Party / Authorisation Registry, to prove that this client is indeed "at the gate of the Service Provider" and it is necessary to ask about his authorisations
  • iSHARE does not prescribe what the input and database storage for authorisation looks like. iSHARE only specifies what the response data structure looks like

Authorisation data model

This section describes the iSHARE delegation data model. Parameters describe what is expected in the model and the response gives an example of what the data model looks like.

Click here to download the entire Authorisation Data Model as a JSON file.

The root delegationEvidence element contains the following parameters:

delegationEvidence
root level
object

The root of any delegation evidence.

notBefore
contained in delegationEvidence
integer

Unix timestamp in UTC indicating the start of validity period of this delegation evidence. SHOULD equal the time of issuing of the evidence unless historic evidence is requested.

notOnOrAfter
contained in delegationEvidence
integer

Unix timestamp in UTC indicating the end of validity period of this delegation evidence. It is up to the issuer off the evidence to set this time. Note that a reasonable amount of time SHOULD be allowed for processing of longer delegation paths. Also note that evidence cannot be revoked, so setting very long validity periods SHOULD be avoided.

policyIssuer
contained in delegationEvidence
string

iSHARE identifier of the delegator (the delegating entity)

target
contained in delegationEvidence
object

MUST for the root level contain an accessSubject. No other elements are allowed. It makes the entire delegation evidence applicable only to this accessSubject.

accessSubject
contained in target
string

iSHARE identifier of the delegate (the entity that receives the delegated rights)

policySets
contained in delegationEvidence
array

Container for one or more objects containing policy elements with an indication for further delegation. Note that policySet elements within one delegationEvidence MUST not restrict each other, but rather offer a mechanism to express additional rights. They MUST be evaluated in a "permit-override" manner, allowing a "Permit" if only one of the policySet elements evaluates to "Permit".

Data structure for root level
{
  "delegationEvidence": {
    "notBefore": 1504683475,
    "nonOnOrAfter": 1504683775,
    "policyIssuer": "EU.EORI.NL123456789",
    "target": {
      "accessSubject": "EU.EORI.NL987654321"
    },
    "policySets": [ ... ]
  }
}

The second level objects in policySets each contain the following parameters. Other parameters are not allowed. Note that XACML spec is heavily restricted, a.o. for the reason to prevent redundancy (and resulting possible conflicts) with the root policySet element.

maxDelegationDepth
contained in policySets
integer

Optional element that, if present, indicates that further delegation of the rights, conveyed in the policy elements that are part of this PolicySet, is allowed. The value indicates the delegation steps that are allowed after this step in order to evaluate the entire delegation path to "Permit"

target
contained in policySets
object

Contains environment

environment
contained in target
object

Contains licenses

licenses
contained in environment
array

Array which describes which iSHARE licenses apply to this policySet.

policies
contained in policySets
array

Used to express the actual rights being delegated. Note that policies within one policySets object MUST not restrict each other, but rather offer a mechanism to express additional rights. They MUST be evaluated in a "permit-override" manner, allowing a "Permit" if only one of the policy elements evaluates to "Permit".

Data structure for policySets level
"policySets": [
      {
        "maxDelegationDepth": 5,
        "target": {
          "environment": {
            "licenses": [
              "string"
            ]
          }
        },
        "policies": [ ... ]
      }
    ]

A Policy element contains the following parameters:

target
contained in policies
object

Describes the target, in terms of resource and action, this policy applies to. It is also the scope that is permitted through the default Rule. Additional Rule elements can be described to exclude Resources and Actions from the default policy rights

resource
contained in target
object

Contains type, identifiers and attributes

type
contained in resource
string

String which describes the type of resource to which the rules apply.

identifiers
contained in resource
array

Optional array of strings containing one or more resource identifiers. If omitted defaults to all attributes. Depending on the Type an identifier SHOULD be a urn.

attributes
contained in resource
array

Optional array of attributes of the resources the delegated rights apply to. If omitted defaults to all attributes. Depending on the Type an attribute SHOULD be a urn.

actions
contained in target
array

Array of actions that apply to this policy. If no actions are listed then the default is to all actions.

environment
contained in target
object

Optional field that contains serviceProviders

serviceProviders
contained in environment
array

Array which lists the iSHARE client ID's of serviceProviders which are allowed to provide services to the accessSubject as described within this policy. If left empty, default is that the policy can be carried out at any Service Provider

rules
contained in policies
array

The first rule element is the default rule that applies to the target at policies level. Note that additional rule elements within one policies object are intended to restrict each the default rule. All rule elements in a Policy MUST be evaluated in a "deny-override" manner, allowing a "Permit" only if all of the rule elements evaluate to "Permit".

Data structure for policy level
"policies": [
          {
            "target": {
              "resource": {
                "type": "CONTAINER.DATA",
                "identifiers": [
                  "ID.12345"
                ],
                "attributes": [
                  "CONTAINER.ETA"
                ]
              },
              "actions": [
                "iSHARE.READ"
              ],
              "environment": {
                "serviceProviders": [
                  "EU.EORI.NL567891234"
                ]
              }
            },
            "rules": [ ... ]
          }
        ]

The default rule element contains the following parameter:

effect
contained in rules
string

MUST containt Permit

Additional rule elements contains the following parameters. Although individually not required, at least one type, identifier or attribute MUST be specified to which additional rules apply:

effect
contained in rules
string

MUST contain Deny

target
contained in rules
object

Describe the target, in terms of resource and action, this additional rule applies to. Additional rule elements are limitations of the default rule and resource scope.

resource
contained in target
array

type
contained in resource
string

Optional string which describes the type of resource to which the rule applies. Defaults to none if not specified.

identifiers
contained in resource
array

Optional array of strings containing one or more resource identifiers. Depending on the type an identifier SHOULD be a urn.

attributes
contained in resource
integer

Optional array of attributes of the resources the delegated rights apply to. If omitted defaults to all attributes. Depending on the type an attribute SHOULD be a urn.

actions
contained in target
array

Optional array of actions, the additional rule applies to the actions listed. If no actions are listed then the default is to all iSHARE actions defined within the policy.

Data structure for rules level
"rules": [
              {
                "effect": "Permit"
              },
              {
                "effect": "Deny",
                "target": {
                  "resource": {
                    "type": "CONTAINER.DATA",
                    "identifiers": [
                      "ID.12378",
                      "ID.12379"
                    ],
                    "attributes": [
                      "CONTAINER.WEIGHT"
                    ]
                  }
                }
              }
            ]

Full data model

Combining all different levels within the Authorisation Data Model results in a full piece of delegationEvidence.

Click here to download the full data model in JSON format

Full Authorisation data model
{
  "delegationEvidence": {
    "notBefore": 1504683475,
    "nonOnOrAfter": 1504683775,
    "policyIssuer": "EU.EORI.NL123456789",
    "target": {
      "accessSubject": "EU.EORI.NL987654321"
    },
    "policySets": [
      {
        "maxDelegationDepth": 5,
        "target": {
          "environment": {
            "licenses": [
              "string"
            ]
          }
        },
        "policies": [
          {
            "target": {
              "resource": {
                "type": "CONTAINER.DATA",
                "identifiers": [
                  "ID.12345"
                ],
                "attributes": [
                  "CONTAINER.ETA"
                ]
              },
              "actions": [
                "iSHARE.READ"
              ],
              "environment": {
                "serviceProviders": [
                  "EU.EORI.NL567891234"
                ]
              }
            },
            "rules": [
              {
                "effect": "Permit"
              },
              {
                "effect": "Deny",
                "target": {
                  "resource": {
                    "type": "CONTAINER.DATA",
                    "identifiers": [
                      "ID.12378",
                      "ID.12379"
                    ],
                    "attributes": [
                      "CONTAINER.WEIGHT"
                    ]
                  }
                }
              }
            ]
          }
        ]
      }
    ]
  }
}

Human authorisation

Description

Besides authorisation on an organisational level, within iSHARE it is also possible to authorise humans to act on behalf of another organisation.

Authorisation of a human is done by replacing the 'accessSubject' value on the root level in delegationEvidence with an iSHARE Pseudonym of the human user.

Authorisation in OpenID Connect flow

The generic OpenID Connect 1.0 flow does not take into account Authorisations of a human. However, in iSHARE it is essential that authorisations of a user are combined with their identity details before a service can be offered.

Within iSHARE, authorisations of a human are registered at an Identity Provider, and are retrieved using the userinfo endpoint. For this purpose, there are some modifications to the OpenID Connect Flow. User identities are protected by sharing pseudonyms in order to comply with privacy requirements.

In some cases, it is necessary to encrypt JWTs. The JWE specification is introduced for this. This is necessary in order to prevent unsuspecting users from being able to read and infer data not meant for them.

Broadly, user's interaction with the service provider can happen in 2 ways:

  • The service specific approach. The user has the specific link to a specific service and is only interested in using that service. The service provider only needs to check if the human user is authorised to access this service.
  • The portal approach. The user uses a portal to access a service. The Service Provider needs to know the authorizations of the user in order to only show services available to the user.

Service specific approach

In the service specific approach, the Service Provider will ask for a specific authorization of the human user in the request parameter of the userinfo endpoint. This request closely follows the delegation mask specification as defined above. However, the value for the 'accessSubject' on the root level of the delegationEvidence is replaced with the iSHARE Pseudonym of the human user.

Portal approach

In the portal approach, the Service Provider is allowed to do a wildcard request in the request parameter of the userinfo endpoint. This request closely follows the delegation mask specification as defined above. However, the value for the 'accessSubject' on the root level of the delegationEvidence is replaced with the iSHARE Pseudonym of the human user. The wildstar is allowed because the Service Provider needs to know all the authorizations of the human user in order to show them in the portal, before the human user can select the correct service. Since a human user would be representing only one company at a time, it is asker by the IDP to select the company it wants to represenent when the user identity is common for different companies it can represent.

iSHARE Technical standards

iSHARE can be described as an API architecture, which enables all parties involved to engage in direct communication. For interoperability reasons, iSHARE makes use of widely used open standards. Modified implementations of OAuth 2.0 and OpenID Connect 1.0 are used to facilitate an ecosystem in which parties can interact with previously unknown parties. Pre-registration, therefore, is not a prerequisite and this requires alterations to the official standards. Also, for the authentication of parties within an iSHARE context, iSHARE uses PKI and digital certificates relating to all participating parties.

API
Architectural principle

Application Programming Interface

APIs are used in iSHARE to facilitate direct and realtime communication between different parties, eliminating the need for a central platform.

iSHARE APIs are designed to be RESTful, and JSON is used for structuring data.

iSHARE prescribes caching requirements relating to the use of APIs in various situations.

Additional API information
An API (Application Programming Interface) is a technical interface, consisting of a set of protocols and data structuring standards ('API specifications') which enables computer systems to directly communicate with each other. Data or services can be directly requested from a server by adhering to the protocols. APIs are used to hide the full complexity of software and make it easy for third parties to use parts of software or data services. APIs are mainly meant for developers to make the creation of new applications depending on other applications easier.
Caching
Performance efficiency

Often data is temporarily stored on a different medium, to enable faster access to the data.

For every API exposed under iSHARE caching MUST Be made explicit to the API consumer.

Caching requirements

If a response is not cacheable it MUST contain the following headers:

Cache-Control: no-store
Pragma: no-cache

If a response is cacheable it MUST contain the following headers:

Cache-Control: max-age=31536000
Note: max-age MAY vary
HTTP(S)
Communication protocol

HyperText Transfer Protocol (Secure)

iSHARE Scheme communication MUST be carried out over the HTTP protocol, and secured through TLS 1.2 resulting in HTTPS.

iSHARE authentication/authorisation data is generally transferred in HTTP Headers. These headers can become very large when containing multiple encrypted certificates or JWT's. iSHARE parties SHOULD configure their web servers to accept HTTP headers of 100K length to minimise implementation impact on current services.

The most recent version of the HTTP specification can be found here.

Relevant iSHARE HTTP Response codes
After sending a HTTP request to a server, the server responds with (among others) a Status Code which indicates the outcome of the request made to the server.
                  
HTTP verb CRUD Entire Collection (e.g. /customers) Specific Item (e.g. /customers/{id})
POST Create 201 (Created), 'Location' header with link to /customers/{id} containing new ID. 404 (Not Found), 409 (Conflict) if resource already exists.
GET Read 200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists. 200 (OK), single customer. 404 (Not Found), if ID not found or invalid.
PUT Update/Replace 404 (Not Found), unless you want to update/replace every resource in the entire collection. 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
PATCH Update/Modify 404 (Not Found), unless you want to modify the collection itself. 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
DELETE Delete 404 (Not Found), unless you want to delete the whole collection—not often desirable. 200 (OK). 404 (Not Found), if ID not found or invalid.
JSON
Data formatting standard

JavaScript Object Notation

Within iSHARE, JSON is used as data structuring standard for scheme related communication. For the most recent version of the JSON specification click here.

Additional JSON information
JSON is an open standard data format that does not depend on a specific programming language. This compact data format makes use of human-readable (easy to read) text to exchange data objects (structured data) between applications and for data storage. 
JSON Web Token
Open standard for tokens

JSON Web Token (JWT)

A JSON Web Token (JWT) is used in iSHARE when exchanging claims between parties. These claims are signed using the JSON Web Signature (JWS) standard to ensure non-repudiation of these claims.

This section describes how iSHARE uses JWTs and what the specifications for iSHARE JWTs are, while the official standard can be found here.

Additional JWT information
JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.
                  

Because of its size, it can be sent through an URL, POST parameter, or inside an HTTP header. Additionally, due to its size its transmission is fast.

OAuth 2.0
Authentication Framework

iSHARE uses the OAuth 2.0 protocol for authenticating parties and providing access tokens when requesting access to a service within iSHARE. For the most recent version of the OAuth 2.0 specification click here.

The generic iSHARE Authentication flow is found in this section of this Developer Portal.

Additional OAuth 2.0 information
OAuth is an open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets without actually sharing the initial, related, single logon credential. In authentication parlance, this is known as secure, third-party, user-agent, delegated authorization.
OpenID Connect 1.0
Authentication Protocol

Used to obtain identity information for a human subject. Click here for the OpenID Connect 1.0 specifications.

Besides authenticating a human subject, the OpenID Connect flow can also be used to communicate information of the human subject to a server.

Just as in OAuth 2.0, iSHARE deviates from the original standard to allow for information exchange with previously unknown parties. Identity Providers need to provide API access to iSHARE participants based on whitelisted PKI, clients need not to be pre-registered at an Identity Provider.

This section describes the OpenID Connect flow more in-depth.

Additional OpenID Connect information
OpenID Connect is an additional authentication protocol on top of the OAuth framework specific for human subjects.
PKI
Architectural principle

Public Key Infrastructure

System for issuing and managing digital certificates. For authentication purposes, iSHARE requires adhering and Certified Parties to acquire an X.509 certificate which is distributed by a trusted root under certain PKI's (Public Key Infrastructure). For interoperability on a European scale, all trusted roots under the eIDAS regulation will be trusted within iSHARE. However, initially, this will be limited to certificates issued under PKIoverheid.

Trusted roots and eIDAS

The eIDAS regulation aims to provide secure and seamless electronic interactions between businesses, citizens and public authorities throughout the entire EU. A main part of this regulation is that each EU country is required to establish and maintain 'trusted lists', among which trusted root information is found. Each EU country is required to implement these trusted lists in their own countries. Therefore, iSHARE aims to make use of these trusted lists as trust roots within iSHARE to ensure secure and seamless interaction throughout the EU.

During the initial phase of iSHARE, the use of digital certificates will be limited to PKIoverheid certificates only.

Additional PKI information
A PKI is a system for distribution and management of digital keys and certificates, which enables secure authentication of parties interacting with each other.
                  

Generally, three different methods exist for creating trust within PKI's. These are through 'Certificate Authorities', 'Web of Trust' and 'Simple PKI'. Within iSHARE the 'Certificate Authority' approach is used, and as such the other methods will not be discussed.

A PKI can be considered as a chain of certificates. At the beginning of the chain is the root 'Certificate Authority' (CA), a public trusted party which is allowed to digitally sign their own certificates (SSC, self-signed certificate). This 'Root CA' distributes certificates and encryption keys to organisations. The certificate is signed by the 'root CA' as proof that the owner of the certificate is trusted. These organisations can start issuing certificates as well, if allowed by their root. They become CA's, and as such sign the certificates that they issue. Repeating these steps, a chain of certificates is created, with each certificate signed by the CA who issued the certificate.

Parties need to trust a certificate for authentication purposes. Instead of trusting individual certificates of organisations, root certificates can be trusted. By trusting a root, all certificates that have the root within their PKI chains are automatically trusted. Most large root CA's are automatically trusted within web browsers, enabling computers to safely interact with most web servers.

RESTful
Architectural principle for API design

Representational State Transfer

Within iSHARE RESTful architectural principles MUST be applied to the APIs that are specified.

A RESTful API indicates that the API architecture follows REST 'constraints'. Constraints restrict the way that servers respond and process client requests, in order to preserve the design goals which are intended by applying REST. Goals of REST are, among others, performance and scalability. Both are of utmost importance in iSHARE.

Additional RESTful information
REST is an architectural style for building systems and services, systems adhering to this architectural style are commonly referred to as 'RESTful systems'. REST itself is not a formal standard, but it is an architecture that applies various common technical standards such as HTTP, JSON and URI.

RESTful systems are able to process common HTTP operations, such as GET, POST and DELETE.

TLS 1.2
Cryptographic protocol

Transport Layer Security

Within iSHARE, TLS 1.2 MUST be used for securing all HTTP communications. For the most recent version of the specification click here.

Additional TLS 1.2 information
Transport Layer Security (TLS) is a cryptographic protocol that describes communication security for computer networks. It is used to secure the HTTP protocol, resulting in HTTPS.
UTC
Time notation standard

Coordinated Universal Time

In iSHARE all dates and times MUST be communicated in UTC time.

All dates and times MUST be formatted in the Unix timestamp format.

Additional UTC/Unix information
The unix time stamp is a way to track time as a running total of seconds. This count starts at the Unix Epoch on January 1st, 1970 at UTC. Therefore, the unix time stamp is merely the number of seconds between a particular date and the Unix Epoch.
                  

For example, on 7:34 PM (UTC) on the 4th of September 2018, 1536089675 seconds have passed since January 1st, 1970 at UTC. The Unix formatted timestamp is therefore 1536089675

This Unix formatting of UTC point in time technically does not change no matter where you are located on the globe. This is very useful to computer systems for tracking and sorting dated information in dynamic and distributed applications both online and client side.

XACML 3.0
Data Structuring standard for authorisation policies

eXtensible Access Control Markup Language

XML-based standard for defining authorisation policies. Within iSHARE, a JSON port of XACML 3.0 is used to enable parties to communicate delegation evidence. click here for the most recent version of this specification.

This section describes the iSHARE Data Model for authorisation

Additional XACML 3.0 information
XACML (eXtensible Access Control Markup Language) is an XML-based specification that is designed to control access to applications. One of the main advantages of this specification is that applications and systems with their own and different authorization structure can be integrated into one authorization scheme. authorization and the rules surrounding it can be managed centrally regardless of authorization mechanism of the applications themselves. This phenomenon is called externalisation. XACML is derived from SAML and provides the underlying specification for ABAC (Attribute-Based Access Control). XACML is also suitable to be used in combination with RBAC (Role-Based Access Control).
                  

Moreover, with the help of XACML authorization can be arranged and managed in detail. This is called fine-grained authorization . XACML supports the use of security labels, rules with arbitrary attributes, rules with a certain duration and dynamic rules.

In XACML two main functions can be distinguished. One function defines the criteria with which authorization are assigned, such as 'only an experienced user from department X is allowed to modify documents’. The other function compares the criteria with the rules or policies to determine whether a person is allowed to perform the operation on the object or not.

The architecture of XACML is fairly complex. This is partly due to the fact that it is difficult to fit the various components of XACML in the application landscape. These components should be positioned in such a way that the owner of the data can somehow control the authorization to his or her data, but at the same time the components should be positioned in such a way that the performance is not negatively influenced. This is extra important when independent parties need to cooperate with each other and want to jointly organise the access to their applications. Finally, applications need to be compatible with XACML.

X.509
Standard for public key certificates

X.509 is a cryptographic standard for public key infrastructures (PKI’s), used in iSHARE, that specifies the management of digital certificates and public-key encryption and keys of the Transport Layer Security (TLS) protocol that is used to secure web and email communication. The most recent version of this specification can be found here.

Additional X.509 information
In cryptography, X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS[1], the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.

Questions?

Visit the iSHARE community forum