AS-RO policy delegation

[fimbault]

cf discussion on mailing list and buried in ietf-wg-gnap/gnap-core-protocol#145

The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions. AS-RS should not need to understand those policies. The flow would be

• RO contacts AS-RS and gets one or more access tokens.
• RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO.
• A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO.
• That user presents the access token delegated by AS-RO when invoking the resource.

AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made. AS-RS does not need to understand the policy behind granting the delegation by AS-RO.

[fimbault]

Taking one of Denis's feedback, "I need to confess that I have not been able to understand what Alan was meaning with the term AS-RO." (I too have struggled quite a bit).

We should first have a definition for that

[jricher]

I think it's important to discuss things in terms of relationships, and "AS-RS" and "AS-RO" are both reasonable relationships. However, the pattern here has one assumption that I don't think works: there are two separate AS's and they give access tokens to each other. This crosses the roles and confuses the conversation.

If an AS receives and processes an access token, it is acting as an RS. There are two transactions at the same time and one entity plays different roles in each. If an RS requests a token in response to an incoming request, that RS is now a client instance.

Each role is defined by what it does, and if a given party does multiple things then they are acting in multiple roles. We need to stop thinking and talking in terms of deployment patterns for these multi-tiered use cases, and instead look at things in terms of the protocols between the roles. I think it's there that we'll find more clarity.

[fimbault]

If an AS receives and processes an access token, it is acting as an RS.

Indeed (or maybe as an agent)

[jricher]

No, by definition the party that accepts and processes the access token and associates it with a right of access is the RS.

The way an agent fits in, in my personal view, is as another input into the system. So I think the "AS-RO" in the list above isn't an AS, but could be an agent. The artifact that it gives is not an access token, or at the very least not the same kind of thing that the AS-RS puts out for consumption at the RS.

[fimbault]

Yes, that's what I was clumsily suggesting ;-)

But that doesn't fit the flow described at the top (there the AS-RO is really an AS, kind of acting as an RS - well that's the issue)

[Denisthemalice]

There is still no definition to explain what mean the acronyms AS-RO and AS-RS.

:-(

@jricher: You wrote: "AS-RS" and "AS-RO" are both reasonable relationships.

An AS can have many relationships with a RS and until these relationships is described one by one in terms of trust relationships,
we can argue for ever.

An AS can have many relationships with a RO and until these relationships is described one by one in terms of trust relationships,
we can argue for ever.

Please re-read carefully again: An entity A is trusting an entity B for some kind of action C.

For example: "An AS is trusting a RS for some kind of action C.*

When we will have identified the complete set of trust relationships, then we will be able to build the protocols.

I expect more than a dozen of these.

[agropper]

My definition of an AS is the role that turns a request into an access token. Notionally, an AS is the Policy Decision Point, although I see a range of definitions for PDP.

[Denisthemalice]

Since there is still no definition to explain what mean the acronyms AS-RO and AS-RS,
I have created my own terminology RO-AS and RO-RS and wrote a full story including
the definitions of a RO-AS and RO-RS.

I am using the following vocabulary/definitions:

Resource : any object an API can perform an operation (or method) on it.

Resource Server : any system that contains resources/objects on which clients are willing to perform an operation on them.

Note well that RS is a system and thus should not be confused with a (single) resource since a system manages a lot objects/resources.

Resource Owner (RO) : “entity that may grant or deny operations on resources/objects it has authority upon”

The definition of a RO purposely does not state where the RO is located and how it relates to the RO and/or to the RS.

In some cases it may be easier to manage access control rules with an RO agent co-located with the AS, while in some other cases, it may be simpler to manage access control rules with an RO agent co-located with the RS.

The first case is an access control management which corresponds to the use of capabilities issued by the AS but under the control of the RO of the object that the client is willing to access. The implication is that the AS is working in close collaboration with several ROs.

The term "RO-AS" is used to identify a RO responsible of an object on a RS working in close collaboration with an AS.

The second case is an access control management done by the RO of the object (and NOT directly by the RS) using ACLs. The implication is that the RS is working in close collaboration with several ROs.

The term "RO-RS" is used to identify a RO working in close collaboration with a RS.

Now, let us look at what happens when a client wants to perform a given method on a given object at a given RS. In order to simplify, let us assume that the client already knows which AS to call and that it has agreed to call that AS for some set of privileges.

The case of the RO-AS (capabilities)

Let us assume that, at this point of time, the client already knows that it needs to present a capability for that object and that such capability needs to be contained inside an access token issued by that AS.

The client requests to the AS to deliver an access token that contains a capability allowing it to perform a given method on a given object at a given RS. The AS will internally forward the request to the RO (RO-AS) responsible of that object on that given AS. The RO (RO-AS) will take the decision to grant or not the access token.

At this point of time, the AS needs to identify which RO-AS it should call. In order to solve this concern, let us introduce a new entity : an Authorization Server Administrator.

The definition of this new term is:

Authorization Server Administrator: person with rights and responsibilities that has the overall control of an Authorization Server.

This person will indicate to the AS which RO is responsible for the management of which objects. The RO may be a process or a human being.

Before looking at what happens on the RS side, let us address the case of the RO-RS (ACLs).

The case of the RO-RS (ACLs)

Let us also assume that, at this point of time, the client already knows that it needs to present some set of attributes.

Note: The end-user is able to query at any time the AS to know the set of attributes managed by the AS.

The client requests to the AS to deliver an access token that contains some set of attributes.

Note: There are both advantages and drawbacks to reveal to the AS the identifier of the RS at this point, of time.

Let us now suppose that an access token that contains some attributes is delivered by the AS and is then presented to the RS in addition to an identifier of the object and the operation/method that it wants to perform on that object.

The RS will internally forward the request to the RO (RO-RS) responsible of that object on that given RS.

At this point of time, the RS needs to identify which RO-RS it should call. In order to solve this concern, let us introduce a new entity: a Resource Server Administrator.

Resource Server Administrator: person with rights and responsibilities that has the overall control of a Resource Server.

This person will indicate to the RS which RO is responsible for the management of which objects. The RO may be a process or a human being.

For each trusted AS, the RO (RO-RS) maintains a list of attributes types (and optionally values) that will be accepted among the attributes contained inside the access token.

The attributes contained in the access token will be filtered using this information and then the RO-RS will use the remaining attributes to grant or not the access to the object.

Let us now comeback to the case of the use of capabilities

Let us now suppose that an access token is delivered by the AS which contains a capability. That access token is presented to the RS in addition to an identifier of the object and the operation/method that the client is willing to perform on that object. The RS will internally forward the request to the RO (RO-RS) responsible of that object on that given RS.

For each trusted AS, the RO (RO-RS) maintains a list of operations/methods that will be accepted among the operations/methods contained inside the access token.

The operations/methods contained in the access token will be filtered using this information and then the RO-RS will use the remaining operations/methods to grant or not the access to the object.

Conclusion

In the model, the case of an AS working in collaboration with several ROs and the case of an RS working in collaboration with several ROs are addressed.

This leads to two flavors for ROs since "RO-RS"s SHALL exist on the RS-side and "RO-AS"s MAY exist on the AS side.

Note: A simplification has been done in the description, since the way to counter the end-user collaboration attack is not described.

[fimbault]

ietf-wg-gnap/gnap-core-protocol#224 will create a means to talk about policies

[Denisthemalice]

On March 25, I wrote a long argumentation which tooks me about half a day to write but the only comment I got was
a thumb down from jricher.

I can understand that he does not agree with the text, but I would like to read his arguments.

[agropper]

@Denisthemalice I re-read the summary @fimbault #25 (comment) and it seems clear. Can you start with the one most important issue you have with that description?

[Denisthemalice]

@agropper : As said on March 25 th:

" there is still no definition to explain what mean the acronyms AS-RO and AS-RS" so I am unable to understand the story.

and also:

When we will have identified the complete set of trust relationships, then we will be able to build the protocols.

A this point, I am awaiting answers from jricher.

[fimbault]

As discussed previously, there is an issue to define the trust relationships, and it seems we should now be ready to start working more on that section.

That said, we wouldn't consider the client as the most trusted part, as you have in your model @Denisthemalice

[Denisthemalice]

@fimbault : You wrote:

"we wouldn't consider the client as the most trusted part, as you have in your model.

The wording " most trusted part" is meaningless, since there is no graduation in trust.

On March 24, I wrote:

Please re-read carefully again: An entity A is trusting an entity B for some kind of action C.

[fimbault]

I was referring to your model in which the client is the central piece for privacy protection against the potential of an AS acting as "big brother".
In that model, all clients are indeed considered more trustworthy than the AS, which is a big stretch when looking at real world attacks.

There does exist graduation in trust, although not exactly in the same way as what you're describing. See "promise theory" as a formalization (with much more nuance that just saying A trusts B for C). Ex a promise can be conditional on something else.

[jricher]

I believe this issue has been thoroughly discussed and no actionable conclusion has been reached, and the issue will be closed.