Trust relationships

[Denisthemalice]

At the moment, there is no text in the draft to describe the relationships and/or the trust relationships between the various components of the system. The following is a first attempt to define these relationships.

First of all, I have revisited two definitions:

a) Privilege : The current definition is : right or attribute associated with a subject

Since the term "subject" is still being debated, in this case the term "end-user" is more appropriate, which leads to :

Privilege : right or attribute associated with an end-user

b) Client : The current definition is : application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs

Saying that the client consumes resources from one or several RS is not accurate enough. Since we are only considering the case of APIs, it would be more appropriate to use the wording "operations on objects", which leads to:

Client : application operated by an end-user that attempts to perform operations to objects managed by one or several RSs, possibly requiring access privileges from one or several ASs

It is important to recall what means trust as defined in ISO/IEC 10181-1:1996 in section 3.3.28:

trust

Entity X is said to trust entity Y for a set of activities if and only if entity X relies upon entity Y behaving in a particular way with respect to the activities.

The components of the model are: (1) end-users, (2) clients, (3) Authorization Servers, (4) Resource Servers, (5) Resources Owners and (6) Access Tokens.

The following definitions are being used:

(1) End-user : natural person that operates a client instance

(2) Client : application operated by an end-user that attempts to perform operations on objects managed by one or several RSs, possibly requiring access privileges from one or several ASs

(3) Authorization Server (AS) : server that grants delegated privileges to a particular instance of client software in the form of an access token and other information

(4) Resource Server (RS): server that provides operations to objects referenced by specific client application requests

(5) Resource Owner (RO) : entity that may grant or deny operations on objects it has authority upon. See issue #2XX about this definition versus the current definition

(6) Access Token: a data artifact representing a set of rights and/or attributes

Since the last sentence above addresses two cases, i.e. a set of rights and/or attributes, it appears useful to give guidance for each case.

Hereafter is a proposed text to be inserted with Section 3.2 of the document.

When an access token is representing a set of rights, that access token gives to the client the ability to perform a set of operations on an object. This ability is granted by a RO recognized by the AS to have the right to issue capabilities on that object. When received by the RS, the access token is communicated to the RO protecting the object at the RS in order to be compared with a set of rules specified by that RO which allows or denies to perform the requested operation on the object. Such a scheme is usually called an access control scheme based on capabilities.

When an access token is representing a set of attributes, the access token contains a set of attributes relative to an end-user that will be compared with another set of attributes expected by the RO protecting the object at the RS. If there is a match, the access token allows to perform the requested operation on the object. Such a scheme is usually called a access control scheme based on ACLs (Access Control Lists).

The end-user is trusting his client to manage the interactions with the AS and with the RS whether these interactions are performed using APIs or using a User Interface (UI).

The end-user is trusting the AS to manage his attributes and, upon request, to provide a subset of them inside an access token or simply to disclose them to the client.

An AS MAY recognize and trusts some ROs as being able to grant some operations on objects they have authority upon. These ROs are associated with an AS. When an operation is granted, it takes the form of a capability.

Note: In general, an AS does not need to have a prior knowledge of the RSs, nor any kind of trust relationship with the RSs.
When it happens that an AS has a prior relationship with a RS, they MAY both agree on the use of some access token formats.

A RS recognizes and trusts some ROs as being able to grant or deny operations on objects they have authority upon. These ROs are associated with an RS. Granting or denying an operation on an object may be obtained either by presenting a capability (i.e. a right) or some attributes (i.e. when ACLs are being used). When ACLs are being used, different ACL schemes may be supported depending upon the content of these ACLs, such as Identity Based Access Control (IBAC), Attributes Based Access Control (ABAC) and Role Based Access Control (RBAC).

A RS trusts some ASs or a combination of some ASs to issue some forms and/or some formats of access tokens. Once an access token has been recognized by a RS as being both during its validity period and cryptographically valid, using the reference of the requested object, the RS identifies which RO may grant or deny operations on that object. Then after, the RS is trusting that RO to apply the correct decision. The following data elements are then communicated to the appropriate RO associated with the RS: the reference of the requested object, the operation requested by the client on that object and the content of each received access token. Using this information and possibly information obtained from previous access tokens, the appropriate RO associated with the RS will allow or deny the client to perform the requested operation on the object.

[fimbault]

Thanks, this is supposed to be in a security consideration section, which will be discussed in #135. We'll have to be synthetic, because the document is already fairly long (the remark applies to the rest of the text also).
I think it's a bit early to be able to write that section, but we'll definitely have to do it.

[agropper]

It may be premature to have this discussion. I hope we don’t bake into GNAP an assumption that resources are protected by ACLs as opposed to capabilities. Please see #215 (comment)

[fimbault]

We shouldn't indeed, I think we need to be agnostic as to which mechanism is used to protect the resources.
Although right now, even though the content of the acces token is opaque, relying on JWT (as does OAuth2) and the way the request is made (actions), one can only accommodate specific cases. I think we could generalize by just being able to request roles/groups and various formats (possibly through extensions).

But Adrian's great feedback is also what makes me think we shouldn't try to define in the text an overreaching architecture that really depends on the deployment model.

[fimbault]

Here's my feedback on the initial description of the issue.

Thanks for the proposals for definitions:

a) Privilege : The current definition is : right or attribute associated with a subject
I still think using subject is the right choice, see for instance the AS-RO discussion where the RO (which isn't necessarily an end-user) also has its own set of privileges.

b) Client operations on objects: why not but I'm not sure that any clearer than resources. What is an object here? (I could very well use a not object oriented language). IMHO resources seems fairly well established

Now for the rest of the suggested text:

• As per my previous answers, I'm not sure it's worth having a discussion on capabilities vs ACLs. It's hard to understand for most people (and not get wrong for devs), and it implicitly demands to support at least 2 types of tokens (which we said won't be the case in the core spec).

• "When an access token is representing a set of attributes": technically we don't really have that currently, there's only actions. Before we introduce this text, it makes sense to first decide whether we allow additional requests for access tokens, similarly to what has been described with roles/groups in 203. I would personally be in favor of supporting that.

• "The end-user is trusting his client to manage the interactions with the AS and with the RS". Yes

• "The end-user is trusting the AS to manage his attributes and, upon request, to provide a subset of them inside an access token or simply to disclose them to the client." Yes, apart from the "simply disclose them to the client" (opaque by default, at least in the core spec).

• "An AS MAY recognize and trusts some ROs as being able to grant some operations on objects they have authority upon. These ROs are associated with an AS." Yes (cf discussion on objects above). Associated is not that clear.

• Some parts (relationship between AS and RS) would be better suited for an extension document. Some of those items may have to be discussed at the same time as other proposals (cf Adrian and Alan's AS-RO).

[Denisthemalice]

@fimbault First of all: Thank you for your feedback !

Your text:

a) Privilege : The current definition is : right or attribute associated with a subject
I still think using subject is the right choice, see for instance the AS-RO discussion where the RO (which isn't necessarily an end-user) also has its own set of privileges.

My response:

Until someone can explain what an AS-RO is (by defining this abbreviation), I believe that "end-user" remains adequate.

Your text:

b) Client operations on objects: why not but I'm not sure that any clearer than resources. What is an object here? (I could very well use a not object oriented language). IMHO resources seems fairly well established

My response:

This has nothing to do with an object oriented language: A resource is any object an API can perform an operation on it.

Your text:

Now for the rest of the suggested text: As per my previous answers, I'm not sure it's worth having a discussion on capabilities vs ACLs.

My response:

People in this working group are supposed to be security experts that understand what "access control rules" are.
I have been a teacher during more than 20 years in an engineering school and I have always addressed ACLs versus capabilities every year. I do know that students understand immediately what an ACL is and I also do know that it is more difficult to let them understand what a capability is since 99 % of the systems are primarily using ACLs.

Since a privilege is either a right or an attribute, you nearly have the two facets on the coin:

A right is a permission on an object and thus is a capability

while

An attribute is any characteristics associated with an entity.

It is used as one of the two components of ACLs which include for a given object: an attribute and the method(s) associated with this attribute for that object.

Your text:

It's hard to understand for most people (and not get wrong for devs), and it implicitly demands to support at least 2 types of tokens (which we said won't be the case in the core spec).

My response:

It is not two types of access tokens but one type of access token that will necessarily carry at least ONE attribute and MAY also carry rights. It is important to read the last sentence twice since you would have expected the following sentence:

"One type of access token that carries either attributes or rights".

When the access token contains attributes, these attributes may be an identifier, a first name, a name, an email address, a home address, a gender, an age, a citizenship, a country of residence, etc. ...

When the access token contains a right, e.g. a GET or a POST on some object hosted by a RS, FOR SECURITY REASONS it shall also include a subject identifier in order to counter a user collusion attack. The JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens contains the following sentence:

This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely on that
information for performing tasks such as correlating incoming
requests with data stored locally for the authenticated principal.

Since we are going to consider sub_ids, this sentence will need to be extended for "sub_id" claims as well.

Your text:

"When an access token is representing a set of attributes": technically we don't really have that currently, there's only actions. Before we introduce this text, it makes sense to first decide whether we allow additional requests for access tokens, similarly to what has been described with roles/groups in 203. I would personally be in favor of supporting that.

My response:

According to my previous response, you should not only include actions, unless you knowingly accept this access token to be transmitted maliciously from one client to another client. This is conceivable for a GET operation but not for a DELETE operation.

Your text:

"The end-user is trusting his client to manage the interactions with the AS and with the RS". Yes

My response:

I am glad to see that you accept this trust relationship. This a fundamental building block for GNAP.
I hope to see this sentence in the next revision.

Your text:

"The end-user is trusting the AS to manage his attributes and, upon request, to provide a subset of them inside an access token or simply to disclose them to the client." Yes, apart from the "simply disclose them to the client" (opaque by default, at least in the core spec).

My response:

The end-user is trusting the AS to simply to disclose them [his attributes] to the client."

These attributes are personal information an as such the end-user is allowed to know which attributes are being known by the AS about him. It is simply "Tell me the list of attributes you have about me".

Your text:

"An AS MAY recognize and trusts some ROs as being able to grant some operations on objects they have authority upon. These ROs are associated with an AS." Yes (cf discussion on objects above). Associated is not that clear.

My response:

I would call them now : RO-AS

A RO-AS is a RO trusted by an AS to grant capabilities in advance or to grant them upon request (i.e. when the AS needs to make a decision) for objects placed under his ownership .

Your text:

Some parts (relationship between AS and RS) would be better suited for an extension document. Some of those items may have to be discussed at the same time as other proposals (cf Adrian and Alan's AS-RO).

My response:

" better suited for an extension document" might mean: "swept under the rug" or "postponed indefinitely".

:-(

I need to confess that I have not been able to understand what Alan was meaning with the term AS-RO.
A definition of this abbreviation would help.

[fimbault]

I fear there might be a misunderstanding on ""The end-user is trusting his client to manage the interactions with the AS and with the RS".

That the end-user trusts his client doesn't mean the AS or RS should trust the client. The end-user might be very knowledgeable or not at all on the matter, and so I would consider that as "blind" trust. There are many cases where the end-user is fooled in using a malicious client.

[fimbault]

Regarding definitions

• I created a new issue for AS-RO #223 and asked there for a definition.
• "A resource is any object an API can perform an operation on it." From the outside client, it's the API that we care about. So why would we refer to the internal object?

As for the rest (ACLs vs capabilities), I'll let other people give their opinion. Seems to me more as an implementation detail (and not a trivial one, especially for capabilities) than a trust boundary per say. Why vs How.

[fimbault]

Last the reason why I say 2 types of tokens : I get your point but it's impossible to support a full capability model with JWT for instance (can't attenuate). Alan explained that it's possible to imagine a token exchange mechanism, but still, a cryptographic attenuation is much stronger.

[Denisthemalice]

fimbault ; You wrote:

I fear there might be a misunderstanding on

"The end-user is trusting his client to manage the interactions with the AS and with the RS".

There cannot be a misunderstanding since every trust relationship is necessarily unilateral.

[fimbault]

Sure, but what I mean is that my approval to the sentence doesn't mean we should consider the client is trustworthy (cf opaque discussion), for the reasons mentioned just before. The trust boundaries are defined primarily with respect to the owner's point of view (i.e. what needs to be protected), and so what the end-user trusts might be irrelevant.

[Denisthemalice]

fimbault :

client is trustworthy does not mean anything. An entity A is trusting an entity B for some actions/purposes/behavior C.

Using "trust boundaries"as you mention is not the right way to define trust relationships.
However, you can say that A, B and C are trusting the entity E for some actions/purposes/behavior F.

Then you can illustrate that by drawing a circle around the entities A, B and C to highlight that they have the same relationship with the entity E.

I trust my laptop ... until I suspect that it is infected by a virus, a malware, a spyware, etc ..
In such a case I try to fix the problem before continuing to use it. There is no "owner" point of view.

The model is simple : A is trusting B for some actions/behavior C.

If an end-user trusts nothing at all, then this is the end of the story.

[fimbault]

cf Alan's comment on your definition of trust (which explains why I used trustworthy)

I like your definition of trust, but sometimes it's easier to understand if we turn things around. In what way is entity A vulnerable to entity B? In this case, B might perform C to A's expectations, but B might also do action D, which A did not expect. A privacy violation is an example of D.

The RO might be vulnerable to a wrong trust boundary set at the end-user level (of course, if RO = end-user, the points of view are merged, but please consider the general case in terms of roles: trust depends on what you have to protect, so that should be the starting point, and so "if the RO trusts nothing at all, it's the end of the story")
Example : the end-user (doctor) thinks he's safe when analyzing patient data, but his laptop is locked by a ransomware after the sensitive data has been exfiltrated. The patient (owner) is clearly at risk here, despite the trust that the doctor used to put in his system.

The notion of trust for a human and for machines are different, and so we need to distinguish. How can you trust your laptop, if you can't know for sure it's not been infected? (your lack of suspicion above doesn't make it more trustworthy, it might just be that you ignore the risk / maybe that's reasonable, maybe not). Plus the issue also concerns the client running on your laptop, who knows for sure if it's a legit client? (ok we'll try our best with client posture/attestation, but still). The point being that the client generally can't be considered safe by the user until proven otherwise, it's likely to be one of the most vulnerable components.

IMHO promise theory (Mark Burgess) is probably better suited to describe more formally.

[Denisthemalice]

Three weeks after the opening of this thread, the very first comment unfortunately remains true.

At the moment, there is no text in the draft to describe the relationships and/or the trust relationships between the various components of the system.

Without a clear definition of these relationships, we might continue to argue for ever.

[Denisthemalice]

@jricher : Would you be able to provide some text when capabilities (i.e. rights) are being supported?

[fimbault]

For your information, I'm currently writing the trust relationships section, based on promise theory

The section in the spec won't get into a formal model, but it's possible to do that somewhere else.

[fimbault]

See #306

[fimbault]

Closing following #306