This part of the iSHARE Scheme is considered normative and is therefore compliant with RFC 2119.
This chapter contains information on the generic technical standards that are applied in the iSHARE Scheme, relevant to all parties involved.
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.
...
| Technical standard | Character | Description | ||||||
|---|---|---|---|---|---|---|---|---|
| API | Architectural principle | Application Programming Interface API's are used in iSHARE to facilitate direct and realtime communication between different parties, eliminating the need for a central platform. 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. iSHARE prescribes caching requirements relating to the use of APIs in various situations. | ||||||
| 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. | ||||||
| OAuth 2.0 | Open standard for authentication | Authentication standard, used in iSHARE to gain access to services through access tokens. iSHARE has modified the OAuth 2.0 standard to work without pre-registration. Pre-registration of clients MUST NOT be used. Certificate and status validation with the iSHARE Scheme Owner is sufficient for authentication purposes. If needed, clients can be registered after authenticating. To ensure security in unknown clients, iSHARE prescribes whitelisted Certificate Authorities that MUST be used. The OAuth 2.0 subpage also describes the iSHARE generic Authentication flow. | ||||||
| OpenID Connect 1.0 | Open standard for authentication of humans | Authentication standard for the authentication of humans in an online context. Functions as an additional layer on top of the OAuth 2.0 protocol. | ||||||
| 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. An overview of relevant iSHARE HTTP response codes can be found here. | ||||||
| TLS 1.2 | Cryptographic protocol | Transport Layer Security 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. Within iSHARE, TLS 1.2 MUST be used for securing all HTTP communications. For the most recent version of the specification click on this link. | ||||||
| RESTful | Architectural style for API design | Representational State Transfer 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. 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. RESTful systems are able to process common HTTP operations, such as GET, POST and DELETE. | ||||||
| JSON | Open standard for file formatting | JavaScript Object Notation 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. Within iSHARE, JSON is used as data structuring standard for scheme related communication. For the most recent version of the JSON specification click on this link. | ||||||
| JSON Web Token (JWT) | Open standard for definition of access tokens | JSON Web Token A JSON Web Token (JWT) is used in iSHARE 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. All iSHARE JWTs MUST be signed using the JWS specifications. | ||||||
| XACML 3.0 | Access control policy language | eXtensible Access Control Markup Language Standard for defining authorisation policies. Within iSHARE, a JSON port of XACML 3.0 is used to enable parties to communicate delegation evidence. For the most recent version of the specification click on this link. | ||||||
| X.509 | Standard for the format of public key certificates | X.509 is a cryptographic standard for public key infrastructures (PKI’s) 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. For the most recent version of the specification click on this link. | ||||||
| Time standard | In iSHARE all dates and times MUST be communicated in UTC time. All dates and times MUST be formatted in the Unix timestamp format. |
...