Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

The iSHARE Trust Framework can be characterised as an API (Application Programming Interface) architecture for identification, authentication and authorisation based on a modified version of the widely used OAuth and OpenID Connect standards. The APIs specified for every role enable standardised interaction between computer systems.


Important

APIs manage access to services of an organisation, services that can be consumed by other parties. Services accessible through APIs can let those (machines or humans) that access the service do anything between reading simple data, to receiving complex instructions, to adding information to a database. If a truck's systems send a time and location to another party's 'Estimated Time of Arrival'-service, for example, this service might respond with an an optimal route to take and an Estimated Time of Arrival. Within iSHARE, the terms 'service consumption' and 'service provision' are used to specify how parties interact with each other (with, in this example, the truck's owner the Service Consumer, and the other party the Service Provider). Note that while the word data exchange is not literally in these terms, API service provision and consumption ALWAYS entails data exchange.


The API architecture of the iSHARE Trust Framework also builds upon the following components:

  • PKI and digital certificates;
    For the authentication of parties and machines, iSHARE uses PKI and digital certificates.

  • HTTP over TLS (HTTPS);
    iSHARE uses the commonly used HTTP protocol for its communications, including TLS to encrypt the communications.

  • RESTful architectural style;
    iSHARE uses the RESTful architectural style to structure APIs and HTTP calls.

  • JSON/JWT;
    Data exchanged in the iSHARE context is structured using the JSON standard. Where non-repudiation is required, JWT's are used;

  • XACML. 
    Delegations are structured according to a JSON port of the XACML standard.

The combination of the above standards and protocols leads to a certain dynamic between the roles in the Trust Framework. In essence, Service Consumers acquire a token which allows them to access certain services from certain Service Providers. The roles specified in the Framework are loosely based on the OAuth standard. 

For a full explanation and description of all APIs, standards and protocols, please refer to the Developer Portal. 

  • No labels