Re-opening of: In practice, only rights are supported but attributes should also be supported

[Denisthemalice]

Justin,

You wrote :

The chairs have indicated that the group can re-open issues when more discussion is needed. Individuals are not to simply re-open issues when they don't get the answer they want. This is not productive conversation and driving consensus.

This issue has been discussed at length. The access structure can be extended with anything, including an attributes field if that makes sense to the RS being protected.

On June 3, 2021, I got a private message from Yaron (one of the co-chairs) with a copy to Leif (the other co-chair). That message said:

You can obviously reopen issues if you believe they should not have been closed.

So I have scrupulously followed the instructions of the chairs. In addition, I explicitly asked you:

Please don't close this issue immediately after replying to it.

Despite this request, you closed the issue.

Keep in mind that other members of the WG might be willing to provide their opinion, but your behavior prevents them to do it.

So I re-open the issue.

You wrote:

The access structure can be extended with anything, including an attributes field if that makes sense to the RS being protected

This is wrong since I wrote:

The text does not state: access (array of objects/strings) describes the attributes and the rights that the client

So you claim that attributes are supported whereas in practice they are not supported by the text.

All the arguments are in issue #295 (In practice, only rights are supported but attributes should also be supported).

[aaronpk]

You are welcome to use structured access tokens and put whatever you want in them in an implementation of GNAP. This has been discussed many times so this issue should be closed since it is not bringing up any new information to the discussion.

[jricher]

Even without structured access tokens, the access array can be extended by whatever means you'd like:

it is expected that many APIs will have their own properties, a set of common properties are defined here.

And

It is anticipated that API designers will use a combination of common fields defined in this specification as well as fields specific to the API itself.

So yes, attributes can be covered here if it suits the API.

[Denisthemalice]

@jricher With such a reasoning, I could say : MAC (Mandatory Access Control) is supported because the access array can be extended with elements like "Finance, Confidential" or "Strategy, Top Secret" ... but it will be impossible to inter-operate.

Such an approach would be perfectly valid if we were writing a framework. but we are supposed to write protocols and we are supposed to follow the Standards track where interoperability (by only reading the documents and nothing else) is a MUST.

[jricher]

We are writing a protocol that works at the security layer, not at the API layer. By your argument, HTTP and TCP aren't protocols either because you can build two incompatible APIs on top of them. This is obviously a flawed argument, as anyone can see.

It's exactly the same thing here. The description of the rights of access are not universal by any means, and pretending otherwise would mean this protocol simply would be ignored by the vast majority of the internet.

The protocol needs to be flexible in what it can protect. It's up to the APIs themselves to define compatibility with each other, and the access array is our hook between those worlds.

[Denisthemalice]

@jricher . You wrote : "We are writing a protocol that works at the security layer". Section 12 (Security Considerations) is still rather thin. Here it is:

12. Security Considerations [[ TBD: There are a lot of security considerations to add. ]] All requests have to be over TLS or equivalent as per [BCP195]. Many handles act as shared secrets, though they can be combined with a requirement to provide proof of a key as well

What kind of checks should be done on the access token by the RS in order to accept it or to reject it ? The document is silent about this.

What kind of security is provided to prevent an access token to be forwarded by a RS or by a client ? The document is silent about this.

It is necessary to define and support some fields in the access token (whatever syntax will be used to encode them). We need to include the definition of such an access token structure in the core document.

Since the title of this thread includes the following wording "attributes should also be supported", coming back to the support of attributes, the mechanisms are widely known as Attribute Based Access Control (ABAC) and Role Based Access Control (RBAC).

If ABAC and RBAC cannot be supported "this protocol simply would be ignored by the vast majority of the internet".

Now, if I pull the string, for privacy reasons, the user must be able to be informed of which attributes are requested by the RS to perform a given operation on a resource and it is fundamental :

1. to inform the client or the user about which ASs are able to provide such attributes,
2. to be able to provide to the user the reason for such an attribute request, and
3. to gather the consent of the user.

As you know, the "User Notice " and the "User consent" are currently missing in the document. The various issues related to the support of attributes make a whole.

[jricher]

Access token structure is a consideration of the RS document, not the core document. The client shouldn't know or care what attributes are in the token.

ABAC and RBAC can already be supported.

[Denisthemalice]

The exchanges between the client and the AS as well as between the client and the RS should be part of the core document.

When writing "the client shouldn't know or care what attributes are in the token" you are considering that "the user shouldn't know or care what attributes are in the token" which means that you are only considering users who do not care about their privacy. Such users do exist, but there also exist some other users who care about their privacy.

Are you proposing that we should exclude such other users to take benefits of the use of GNAP ?

You also wrote:

ABAC and RBAC can already be supported.

You will need to explain how by using the current explanations in the document when user's privacy is being considered.

[jricher]

Users do not read access tokens. Access tokens are not meant to be human readable. Many access tokens contain no data at all, internally, but reference other data for a system.

Please avoid language such as "only considering users who do not care about their privacy", it is not constructive to the conversation and is deeply misrepresentative of the situation.

[Denisthemalice]

Users (who care about their privacy) first want an AS to reveal to a RS only attributes that they have have agreed to be revealed. The two privacy properties in such a case are :

• User Notice and
• User Consent.

Secondly, some other users (who also are about their privacy) are willing to be confident that what will be disclosed in the access token or made accessible to a RS by an AS is indeed in accordance with the two previous privacy properties : User Notice and User Consent. In such a case, the third privacy property is called "Transparency".

It is possible to get the first two privacy properties (i.e. User Notice and User Consent) without allowing the user to "read the access token", while the third privacy property (i.e. "Transparency") can only be obtained by allowing the user "to read the access token".

[aaronpk]

@Denisthemalice the system you are describing requires a lot more cooperation between all the parties involved, far beyond the scope of a spec like GNAP.

For example, even if a user can see what is inside the access token to verify the attributes inside it, that does not stop the RS from using that access token to talk to the AS to retrieve additional details about the user.

[Denisthemalice]

Yes, additional transactions are required to support User Notice and User Consent. None is required to support Transparency.

It is a matter of choice whether privacy is considered as important or not.

Token introspection (described in the other document) is OPTIONAL. If it is not supported by the AS, then the example you describe cannot happen.

[fimbault]

This discussion has already been carried out at length in #244 where we investigated various approaches and decided against a generic bucket where one can put anything It is possible to add an attributes field inside of the access array if desired by a given RS, based on the type