A few weeks ago, the Internet Engineering Task Force (IETF) introduced a new Request For Comments (RFC) document about Vectors of Trust, the RFC8485. It is the work of Leif Johansson from the Swedish University Network. The original draft went through 15 iterations since 2015 and Justin Richer from Bespoke Engineering edited the current version.
Enough with the credits, what issue the Vectors of trust document is trying to solve? It seems that the purpose is to bring an effective method to measure the trust of credentials for digital transactions. The two main approaches at the moment are known as Level of Assurance (LoA) and Attribute-Based Access Control (ABAC). Let me try to introduce these to you first.
Level of Assurance: Simplicity gain, information loss
The Level of Assurance approach is pretty straightforward. A client connects to an identity provider using credentials from a user. That identity provider returns a single value that represents how trusted the user of the client is. That single numeric value is then used by the client to determine whether an action can be performed. The values are integers ranging from 1 to 4. The higher the level, the more we can trust the credentials given to perform operations. The more we trust the credentials given, the more likely the client will allow for critical operations to take place.
Let’s say you go clubbing. First, you queue, then you show your ID in order to go through security. Once you went through security, you need to pay for your ticket. Later on, you use your ticket receipt to get a stamp that grants you re-entry. Now you go out of the club to get some fresh air. As you walk back to get in, you are asked to show your stamp. Because you have the stamp the security guard lets you in without further check. Security trusts that your stamp proves that you already paid for entry and that you can legally drink. This example illustrates how the LoA approach works. Now let’s tackle the ABAC approach.
Attribute-Based Access Control: Information gain, simplicity loss
Attribute-Based Access Control is more fine-grained in terms of access. Here, the identity provider provides to a client a bunch of attributes about the user authenticated upon request. From there, it is down to the client to compute whether the user attributes match its conditions to perform an operation. The client can then control every aspect it requires to perform operations. Even though the added information can be beneficial, it breeds greater complexity. Also, you may end up with a monstrous set of attributes to check against which have no upper limit in size.
Now back to the clubbing example. You walk back but you do not get to show a stamp. Instead, you need to show your ID and your receipt. Then the security guard checks your date of birth to make sure it is still valid. After confirming your age again, the security guard checks that you have a receipt to prove that you paid for entry. This will happen every single time you go outside and back in until the party ends. It is heavier of a process but it does allow flexibility in terms of credentials trust.
Enter Vectors of Trust: The balance we deserve between simplicity and clarity?
Vectors of Trust can be seen as either a small set of LoA put together. You can also see them as limited attributes with predefined value ranges you would use with the ABAC approach. This would be correct in both cases. At the end of the day, Vectors of Trust are an attempt to provide information for a client to make a decision about a user transaction without knowing specifics. Yet the client would have relative information about the authentication method, the level of trust for the credentials and so on.
Back to the clubbing break example. You go through security, then purchase your ticket and get a stamp. Except that this time, the stamp has some more information. It states that you paid to get in and that you can legally drink. Which allows the club to extend their policy to let minors. Minors would have a stamp proving they paid to get in but also that they cannot be served alcohol.
The RFC 8485 provides a data model for these Vectors of Trust to be used between communicating parties. That model aims at covering general purpose aspects that an application can map to specific needs. If the general aspects available will not make sense to map for you, you still can extend following the format present in the document. You can even submit your suggestions for the RFC authors to make amendments if they make sense to add are reusable at a global scale. This is one of the great ways to contribute to information technology, the other way is open-source software support but that is for another post.
Once again, thank you for reading and see you next time.
Like this:
Like Loading...
Related
Vectors of trust: Simplify validation for secure transactions
Posted in Stuff
A few weeks ago, the Internet Engineering Task Force (IETF) introduced a new Request For Comments (RFC) document about Vectors of Trust, the RFC8485. It is the work of Leif Johansson from the Swedish University Network. The original draft went through 15 iterations since 2015 and Justin Richer from Bespoke Engineering edited the current version.
Enough with the credits, what issue the Vectors of trust document is trying to solve? It seems that the purpose is to bring an effective method to measure the trust of credentials for digital transactions. The two main approaches at the moment are known as Level of Assurance (LoA) and Attribute-Based Access Control (ABAC). Let me try to introduce these to you first.
Level of Assurance: Simplicity gain, information loss
The Level of Assurance approach is pretty straightforward. A client connects to an identity provider using credentials from a user. That identity provider returns a single value that represents how trusted the user of the client is. That single numeric value is then used by the client to determine whether an action can be performed. The values are integers ranging from 1 to 4. The higher the level, the more we can trust the credentials given to perform operations. The more we trust the credentials given, the more likely the client will allow for critical operations to take place.
Let’s say you go clubbing. First, you queue, then you show your ID in order to go through security. Once you went through security, you need to pay for your ticket. Later on, you use your ticket receipt to get a stamp that grants you re-entry. Now you go out of the club to get some fresh air. As you walk back to get in, you are asked to show your stamp. Because you have the stamp the security guard lets you in without further check. Security trusts that your stamp proves that you already paid for entry and that you can legally drink. This example illustrates how the LoA approach works. Now let’s tackle the ABAC approach.
Attribute-Based Access Control: Information gain, simplicity loss
Attribute-Based Access Control is more fine-grained in terms of access. Here, the identity provider provides to a client a bunch of attributes about the user authenticated upon request. From there, it is down to the client to compute whether the user attributes match its conditions to perform an operation. The client can then control every aspect it requires to perform operations. Even though the added information can be beneficial, it breeds greater complexity. Also, you may end up with a monstrous set of attributes to check against which have no upper limit in size.
Now back to the clubbing example. You walk back but you do not get to show a stamp. Instead, you need to show your ID and your receipt. Then the security guard checks your date of birth to make sure it is still valid. After confirming your age again, the security guard checks that you have a receipt to prove that you paid for entry. This will happen every single time you go outside and back in until the party ends. It is heavier of a process but it does allow flexibility in terms of credentials trust.
Enter Vectors of Trust: The balance we deserve between simplicity and clarity?
Vectors of Trust can be seen as either a small set of LoA put together. You can also see them as limited attributes with predefined value ranges you would use with the ABAC approach. This would be correct in both cases. At the end of the day, Vectors of Trust are an attempt to provide information for a client to make a decision about a user transaction without knowing specifics. Yet the client would have relative information about the authentication method, the level of trust for the credentials and so on.
Back to the clubbing break example. You go through security, then purchase your ticket and get a stamp. Except that this time, the stamp has some more information. It states that you paid to get in and that you can legally drink. Which allows the club to extend their policy to let minors. Minors would have a stamp proving they paid to get in but also that they cannot be served alcohol.
The RFC 8485 provides a data model for these Vectors of Trust to be used between communicating parties. That model aims at covering general purpose aspects that an application can map to specific needs. If the general aspects available will not make sense to map for you, you still can extend following the format present in the document. You can even submit your suggestions for the RFC authors to make amendments if they make sense to add are reusable at a global scale. This is one of the great ways to contribute to information technology, the other way is open-source software support but that is for another post.
Once again, thank you for reading and see you next time.
Share this:
Like this:
Related
Jean-Dominique Nguele
View more postsBe First to Comment