It’s been a busy few months at Ubisecure with a number of presentations at various events throughout Europe – some of which are available on-demand on our Video Resources page. It is great to be at the events, hearing from other industry experts, meeting new people, and not least getting direct feedback from live audiences as you present.  

One of our core topics we’ve been presenting is getting great interest and engagement, and that is the notion of Identity Context.

What is Identity Context?

In business transactions, Identity Context helps to understand the parties involved in a transaction, including their roles, representative rights, responsibilities, and the nature of their engagement in a specific transaction.

Our work at Ubisecure is driven by our shared vision on the future of digital identity:

Combine a highly assured organisation identity with a strongly authenticated individual identity to show who you are, who you represent and the rights you have when representing them.

I’ve written in depth about highly assured organisation identity, and how the value of strongly authenticated individual identity is well known. However, it is the act of combining those two identity classes that gives actual context to the potential interaction and defines the rights of the individual. It is this resultant combined identity that defines the Identity Context and enables the presentation of an aggregated/generated set of rights that are appropriate in that context.

The Value of Context

We all use the value of Identity Context implicitly, often without realising it, but in those circumstances, it is almost always ‘manually’ or at best with administrative control.

In direct interactions we often add context automatically – consider introducing yourself to a new teacher at your child’s school: ‘Hi I’m X, mother/father of Y’. Adding the parental relationship immediately adds context to the interaction and context to your presented identity. Alternatively, it’s almost certain that the first slide of any presentation you have given has established your Identity Context with the audience by including your name and your job title.

The context allows bounds to be known in the scope of the interaction. Additionally, that context will define rights that the individual can assert because they are acting in that context.

The Complexity of Context

Identity Context has value, and we use it already. So, how complex can it be? In short, very complex.

Context is, well, contextual. For a given individual they will operate in many differing contexts at differing times; they may even operate in multiple contexts at the same time. When operating in multiple contexts these can be independent or combined.

Add to this that the rate of change of contexts can be high; either as demanded by external changes, or as demanded by the process itself. A great example of this is privilege application management, where best security practice calls for least privilege by default and shortest possible time of increased privilege. The broader context might not change for several hours, but within that there will be fast-moving point in time contexts (with associated rights) that need to take effect in real time.

The idea of fast-moving context actually meshes very well with the current ‘buzz’ around Zero Trust. Zero Trust is often described as ‘authenticate always, authenticate often’ but in implementation ‘authenticate’ becomes ‘authorise’, noting that you must be known (authenticated) to be authorised.

Authorising often allows for rights to be modified as time and context change.

The Risks of Context

Context defines rights, and often responsibilities. In the previous two examples the context was self-declared. Self-declaration is ‘efficient’, but also sits as the root cause for most fraudulent activities.

Referring back to our vision, discussed at the start of this blog, for a moment:

Combine a highly assured organisation identity with a strongly authenticated individual identity to show who you are, who you represent and the rights you have when representing them.

We talk about a highly assured organisation identity and a strongly authenticated individual identity – we actually get most value when that individual identity is highly assured as well. But there is a third item that needs to have an assurance level – the ‘combination’.

The combination is the linkage between the two identity types. In the examples above, we have Parent and Employee as the specific linkage.

The linkage can be self-declared, verbally – “I am the parent of” – which is a low assurance declaration and therefore, a low assurance combination. Alternatively, that linkage can be verified, for example through a birth certificate and passports.

The assurance level of the linkage directly affects the value of the Identity Context.

For a given eco-system, the assurance levels of identities and linkage will be defined by a Governance Framework. We see a great example of this in the vLEI eco-system (based on verifiable credentials), defined by the GLEIF and supported by Ubisecure. The assurance levels of the organisation, individual and the linkage between the two are prescribed along with process definitions that will, when executed, preserve that assurance level.

In summary…

Identity Context enables significant value – we have seen and talked about a Northern European Government case study (see below) that realised a 99% saving from establishing a highly assured Identity Context and then allowing that to be delegated.

Knowing ‘who you are’ is not sufficient, we need to know the rights you have for the given ‘interaction’.

If you want to know more about Identity Context, and how our team of identity experts can help your organisation benefit from Identity Context, contact us.

Further resources: