Guiding principles

To achieve the goals of the iSHARE Trust Framework, it is paramount to stay close to a set of guiding principles. As time progresses new principles can be defined, existing principles can be adapted or dropped if deemed necessary. The guiding principles were defined using the format as suggested* by TOGAF 9.2 architectural principles.

The following principles define the Trust Framework and must be kept in mind at all times during further development (see details of guiding principles below):

Principle #	Principle name
1	Generic building block to enable data exchange
2	Limited scope: identification, authentication, and authorisation
3	Leverage existing (international) building blocks
4	Agnostic towards nature and content of data
5	Benefits outweigh investment for all types of participants
6	International orientation

Guiding principles details

Principle 1	Generic building block to enable data exchange
Statement	iSHARE provides a generic identification, authentication and authorisation Trust Framework to be used as enabler for data exchange.
Rationale	In every exchange of data, identification, authentication and authorisation are fundamental factors. iSHARE aims to simplify processes of identification, authentication and authorisation as a generic solution to facilitate data exchange.
Implications	The Framework will allow for extension or adaptability so it can be used in situation/sector specific cases; The Framework will not cater to a specific sector or market, it is applicable in an N amount of cases; The Framework will not be a point solution.

Principle 2	Limited scope: identification, authentication, and authorisation
Statement	The iSHARE Trust Framework's scope is limited to topics of identification, authentication and authorisation in the context of data exchange
Rationale	iSHARE aims to improve the circumstances for data exchange and provides focus on the topic of identification, authentication and authorisation. Identification, authentication and authorisation are a fundamental part of any data exchange, but are not solved in a scalable or standardised way at the moment.
Implications	Without this principle, there is a risk of 'scope creep': related topics could take away the focus off the intended topics

Principle 3	Leverage existing (international) building blocks
Statement	Where possible, iSHARE Trust Framework should be realised using existing and proven standards, technology or initiatives
Rationale	By reusing building blocks already available and in use, the impact on organisations to participate in the iSHARE network and the time to adopt the iSHARE Trust Framework are lowered. Standards, technology and initiatives preferably have a broad (international) usage base and are backed by a professional organisation charged with maintenance of the standards, technology or initiatives.
Implications	the Framework will build on or use existing (international) standards, technology or initiatives where possible; the Framework will aim to use open standards, technology or initiatives; the Framework may use proprietary standards, technology or initiatives; if existing and/or proven standards, technology or initiatives do not provide what is needed, alternative solutions will be sought.

Principle 4	Agnostic towards nature and content of data
Statement	The iSHARE Trust Framework does not concern itself with the contents or nature of data
Rationale	Given the generic nature of the iSHARE Trust Framework and the aim to be applicable throughout any sector, it needs to function with any type of possible data and/or any relevant data exchange interaction model. To this end, the contents of data are only considered where it concerns the facilities needed within iSHARE to adequately exchange various types of data (e.g. requirements to security, encryption, etc.). It is up to the participating organisations to ensure that iSHARE adequately fulfils requirements to the process of identification, authentication and authorisation in the context of data exchange.
Implications	the Framework will not specify the (allowed) content of data exchanges done within a data space( iSHARE context); the Framework does not specify content specific data standards; the Framework should not have limitations connected to types of data or standards used.

Principle 5	Benefits outweigh investment for all types of participants
Statement	The iSHARE Trust Framework needs to be attractive to use and implement for all types of participants/roles in the data space.
Rationale	The iSHARE Trust Framework knows different roles with different responsibilities. When a potential participant considers taking a (or multiple) role(s) in the data space, the framework should aim to have the lowest possible threshold to participate for the potential participant. Depending on what the character of the potential participant is (e.g smaller size or larger size organisations) and which role the participant wants to take, this could mean that the impact of implementation needs to be small or that the implementation is kept relatively simple.
Implications	the framework aims to keep thresholds to participate in the data space (e.g. in terms of implementation impact or onboarding/certification effort) as low as possible for all possible roles; the framework strives for the lowest possible impact for participants when changes occur in the future. Changes to used standards will take place; within the framework and its specifications thought needs to be given to how change is dealt with in an efficient way.

Principle 6	International orientation
Statement	The iSHARE Framework needs to look over geographic and sector boundaries to foster international involvement and cooperation
Rationale	Every sector is per definition an international sector. The iSHARE Trust Framework needs to facilitate, to the extent that it is practical and possible, international involvement.
Implications	the Framework needs its participants to provide knowledge and experience on how it can can stay (and become) attractive in the international context.

*Format used for defining guiding principles, based on TOGAF standard:

Principle name	Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: 'support', 'open', 'consider', and for lack of good measure the word 'avoid', itself, be careful with 'manage(ment)', and look for unnecessary adjectives and adverbs (fluff).
Statement	Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organisation to the next. It is vital that the principles statement be unambiguous.
Rationale	Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
Implications	Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: 'How does this affect me?' It is important not to oversimplify, trivialise, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analysed.