[GNAP] Eight issues for discussion before and at the next WG virtual meeting

[Denis <[e-mail]>]

Hello every one,

Most of the following observations have already been advertised in 
previous virtual GNAP meetings as well at the last OAuth workshop 
virtual meeting.
However, time has been lacking to discuss them. Since a GNAP virtual 
meeting is scheduled next week, I have transformed these observations 
into issues,
so that that can be individually discussed in GitHub before the meeting 
and then at the meeting.

I publish the content of eight new posted issues below, so that every 
one can get an overview of all of them and, if interested, can directly 
point to each
of them with a single click.

I have a specific request to the editors: please, do not close any of 
these issues before the next virtual GNAP meeting.

*1.****Trust relationships are still left undefined in GNAP draft-08
*

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/368

**Section 1.4 of draft-08 is supposed to be about “/trust 
relationships/”, but it is not. It is based on “Promise Theory” document 
(302 pages)
where “ /A //promise is a stated intention /”. “ /Each agent defines its 
own valuation function of promises given or received /”.

On page 108 (!), there is a first attempt to define what Trust means:

/Proposal /1 (Trust). An agent’s expectation that a promise will be kept.
It may be assigned a value lying between0 and1, in the manner of a 
_Bayesian probability_/./

Such an approach is confusing : it is mixing trust relationships with 
security threats.

In the IT community, trust is a binary condition (0 or1): either you 
trust something or you don’t. *It is not a Bayesian probability*.

A trust relationship is rather simple and is composed of three parts :

An entity A … is trusting an entity B … for some kind of behavior C.
/…being aware that some conditions “out of control” might happen/

Section 1.4 of draft-08 is failing to indicate the trust relationships 
that may exist between:

- Client instances and end-users,
- End-users and ASs,
- Client instances and ASs,

Trust relationships need to be clear and understandable. Without them, 
it will not be possible to demonstrate the security of the architecture.

In draft-08, the following questions have no answer:

How may a client instance be associated with an end-user ? This is left 
undefined.

How may an AS be confident that a legitimate user is using a given 
client instance ? This is left undefined.

*2. The Authentication of end-users by an AS is currently not required*

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/369

Extract from the Introduction on page 5 of draft-08:

This protocol allows a piece of software, the client instance, to 
request delegated authorization to resource servers and to request 
direct information.(…)
The end-useroperating the software mayinteract with the authorization 
server to authenticate, provide consent, and authorize the request.

Hence, the authentication of end-users by an AS is not required. Does it 
mean that the authentication of the "piece of software" used by an 
end-user SHALL be mandatory ?
If so, how this "piece of software" should associated with end-user is 
left undefined.

Considerations about an end-user for changing that "piece of software" 
or using several pieces of software at the same instant of time are not 
mentioned.

How an AS may associate some rights or attributes with an end-user is 
left undefined.

Note that the EU Payments Services Directive (PSD2) /mandates the use of 
MFA (Multi Factor Authentication) with the AS/.

Why a strong authentication of end-users by an AS would not be 
sufficient, hence avoiding the authentication of "pieces of software" ?


*3.* *R**ights and attributes **SHOULD be equally supported**

*https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/370

The core draft defines:

_Privilege_:right *or attribute *associated with a subject
_Access Token_:a data artifact representing a set of rights *and/or 
attributes*

However, the core draft does not allow a RS to distinguish between 
rights and attributes.

The core protocol should define two fields in an access token request to 
distinguish between rights (i.e. capabilities) and attributes.

A set of standard _attribute types_ should be defined to support ABAC 
(Attribute Based Access Control) :
e.g. first name, family name, birth date, birth location, home address, 
email address, social security number, citizenship(s), etc …

*4.* *Both attributes (ABAC) and capabilities (CBAC) SHOULD be supported
*
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/371

At the moment, a client is able to request with a fine degree a 
precision a specific set of rights that should be included into an 
access token.
However, a client is unable to request a specific set of attributes that 
should be included into an access token.

As a consequence, the /support of rights/ versus the /support of 
attributes/ is unbalanced.

Implicitly, the core draft mandates a /bilateral/pre-relationship 
between every pair of AS / RS. This is not advertised in the draft.

Such bilateral pre-relationship limits the scalability of the architecture.

When attributes only are supported, no /bilateral/ pre-relationship 
between an AS and a RS is necessary.

The core document only implicitly allows an AS to add attributes into an 
access token /at its own discretion/,
without any specific request for them to be included from the client 
(and hence the end-user).

This means that the core document does not allow an AS to add specific 
attributes into an access token upon the request from the client
(and hence from the end-user).

This has *severe consequences in term of the end-user privacy* which are 
not mentioned in the draft.

First of all, since rights are always included, this means that the AS 
MUST be aware of the identity of the RS.
In addition, the AS cannot be kept ignorant of which actions will be 
performed by a client and on which resources.
*This allows the AS to act as "Big Brother"*. However, this can be 
prevented in the case where attributes only are supported.

Secondly, in order to support "good practices" (User Notice, User 
Choice, User Consent and Transparency)or legislation like the EU GDPR,
the end-user should be informed about the set of attributes that are 
requested _by a RS_and should also be able to know the treatment(s)
that will be done with such attributes. At the moment, a dialogue 
between the client and the RS is missing. A specific RS end-point
should be defined and dedicated for such dialogue.

If the end-user agrees to provide that set of attributes to the RS, he 
should be able to indicate to the AS which attributes types(/and 
optionally values/)
should be included into the access token. At the moment, the client is 
unable to specify to the AS a set of attributes to be included into the 
access token.
In addition, an end-user is even unable to know which set of attributes 
are known by the AS.

If this situation is going to last, the privacy consideration section 
should clearly indicate these limitations.

*5. A RS is currently only able to trust a single AS
*
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/372

This limitation should be removed and can be removed. For details, see: 
draft-pinkas-gnap-core-protocol-00.txt

The /Proposal/for a Regulation amending Regulation (EU) No 910/2414 as 
regards establishing a framework for a European Digital Identity
of 3 June 2021 should not be ignored. /It paves the way for the use of 
//multiple////attribute servers//./

If such limitation is not removed, it should be clearly advertised in 
the core draft.

*6.* *Bearer access tokens and key-bound access tokens are not the 
single types of access tokens
*

**https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/373

**OAuth (and GNAP draft-08) postulate that only two classes of access 
tokens may exist:
- key-bound access tokens where the access token is bound to a key used 
by the client instance in its request, and
       - bearer access tokens that do not include a key used by the 
client instance in its request.

If a hardware security module (HSM) is being used, it prevents a 
legitimate client or a user to know the /value //of a client private key/,
but it does not prevent the /use//of that private key/by a legitimate 
client willing to collaborate with another client.

If a client accepts to collaboratewith another client, the use of 
key-bound access tokens does not offer a protection
against the use of an access token by another client.

GNAP (and OAuth) are not resistant to client collaborative attacks.

As long as this situation will last, this should be clearly advertised 
in the draft.

However, there exits a solution to address this issue which has already 
been advertised to the WG: the addition into the access token of a 
"buid" field : Binding User IDentifier.
As a side consequence, a distinction should be done between 
long_term_user_accounts and short_term_user_accountssupported by a RS.

For details, see: draft-pinkas-gnap-core-protocol-00.txt


*7. **Draft-08 makes a general assumption that an end-user and a RO are 
the same entity*

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/374
**

**Extract from page 13 of draft-08:

      Note that the RO and end-user are often the same entity in 
practice, but GNAP makes no general assumption that they are.

Unfortunately, this Note is wrong. Section 1.5 is failing to provide a 
single example where the end-user is not also the RO and where the RO is 
an automated process.

This comment has already made several times, but no action has been made 
to take care of it up to now: section 1.5 has still not been modified.

*8.* *GNAP versus GNAF*: *do the current drafts describe a protocol or a 
framework ?
*
https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/51
*
*_Response_: They describe a framework since two independent 
implementations of the drafts will be unable to interoperate.

In particular, the issue about "Format of defining REQUIRED vs OPTIONAL 
request/response elements 
(https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/257) is still 
opened.

The protocols are not defined end-to-end. In particular, which 
treatments and verifications should be done by a RS are still left 
undefined.

As long as this situation will last, the document cannot be considered 
as a "Grant Negotiation and Authorization *Protocol*" (GNAP)
but rather as a "Grant Negotiation and Authorization *Framework*" (GNAF).


Denis