Hyperty Trust and Security Model

[pchainho]

https://github.com/reTHINK-project/dev-service-framework/blob/d3.2-working-docs/docs/manuals/hyperty-trust.md

[jmcrom]

I would replace both "Identity" and "User identity" sections with this text:

In our modern society, technology is ubiquitous, and transactions are evermore accomplished using digital technologies without the need to involve physical contact. An example of this situation can be observed in money transactions, whilst a few years ago if someone needed to make a bank transfer, it would require that person to move personally into a bank agency to order it, and in current days these money transfers can be performed using a smartphone. To achive this, we need digital credentials to prove who we are and what we arre llowed to do in remote communication. Therefore two important information security mechanisms must be implemented: authentication and authorization.

Authentication is verifying the identity claimed by an actor. Usually, to authenticate users, credentials make use of one or several factors among:

• something a user knows (such as a PIN code or a password),
• something a user owns (such as a SIM card),
• something a user is (such as a fingerprint, or a voice sample),
• something a user does (such as typing characteristics).

Authorization is deciding whether a given identity may execute or access a certain resource. Access control to a service or system, can be achieved based on access rights or policies that allow or deny a particular action based on an identifier, a role (RBAC), or an attribute (ABAC).

[Ricardo-Chaves]

Sounds good for me.

[rebecca-copeland]

While I agree with the text, should this be part of D3.2?

The main point (which is made but not emphasized by Jean-Michel) is that (you can use this text) "The reTHINK design of the communication services does not include the identification of the user. It relies on service-independent authentication that is global and non-service-bound. In implementations, each reTHINK service provider may include their own user recognition (i.e. their own internal user accounts) and service authorization (i.e. level of permissions to use the service), over and above the initial user identification. This means that service providers can maintain their own association lists."

The identity rules (what a user knows, is, owns) is usually mentioned as a trio, while the forth (usually mentioned separately) is a 'shared secret' - rather than 'what a user does'.

When it comes to RBAC and similar schemes, much more is involved, including user's role and job description in an organization and in particular departments and so on.

I like to analogy to mobile P2P banking!!! It shows that the authentication needs to have a high level of trust before the money transfer can be made. You need to distinguish this from 'Mobile money' services that merely find the bank account (or credit account) by using the phone number...

In P2P mobile money transfer, the Mobile operator uses their phone identification system as an IdP. It verifies the recipient by their trusted IdP (the phone operator of the other party). Then the transaction takes place - I think still using a credit service provider, i.e. not entirely direct, and not without any audit trail... By analogy, reTHINK P2P conversations, streaming or data must still go through some edge servers belonging to the service providers, which check security.

My best,

Rebecca

[jmcrom]

@rebecca-copeland the forth is a subclass of biometrics

• whet a user is = based upon morphology (such as fingerprint, iris, recognition blood vessel design)
• what a user does = based upon behaviour

'shared sescret' looks like a "what a user knows" to me

[pchainho]

I've just updated the doc according to your proposals (many thanks). Pls have a look

@rebecca-copeland this document will be provided to developers in the service framework gitub repo to give them an overview about the Hyperty Trust and Security model. But I'm fine to have it in D4.2