Requesting User Information

[Denisthemalice]

In section 2.4 (Requesting User Information), the first sentence starts with:

 If the client instance is requesting information about the RO from the AS, ...

From the title, the acronym "RO" should be changed into "end-user". The case where the RO is also the end-user is a specific case.

This leads to the following change:

 If the client instance is requesting information about the end-user from the AS, ...

In the following sentences of this section, RO should be changed into end-user.

[fimbault]

The current text really means RO, and generally considers the case end-user = RO.
Any other case would even trigger an error: "If the identified end-user does not match the RO present at the AS during an interaction step, the AS SHOULD reject the request with an error." (section 2.4)
Which makes sense because why would we return something about the RO to a potentially unknown end-user? (the only problem is that this wording is buried in the text, so it's hard to understand)

Back to the general case:
The RO is in control of policies at the AS. The end-user is in control of a client and a request to the AS. The end-user and client may or may not have any prior relationship with the AS. The subject info is what is known by the AS (in theory could be RO and maybe end-user, but notice that in the terminology, we define the end-user as a natural person and the RO as a subject entity).

I think we should clarify when we could have a remote RO too. Then do we even return a result if the AS knows something about the end-user? (different from RO in that case).
Plus we need to keep in mind that we also use sub_ids for request.user.

In general, we might want to avoid the term "user" as it is not specific enough.

[Denisthemalice]

The title has been changed into "Requesting Subject information".
This title is incorrect as long as a subject can be also an organization or a device.

An AS can hold information about an end-user or about RO when the RO is a human being. It does not hold information about organizations or devices. However, an end-user may belong to some organizations or/and use some devices.

IMO, I would replace it by "Requesting end-user Information".
If an AS holds information about an end-user, it seems logical that the end-user should have access to it.

If it happens that the end-user has also a RO account on the AS, then it should also have access to it.
In such a case, another section with the following title "Requesting RO Information" should be created.

RO = end-user was a common case in OAuth. In GNAP and in the general case a RO is different from an end-user and an AS may have no relationship with any RO (e.g. when attributes only are being used).

[fimbault]

I guess you refer to "2.2. Requesting Subject Information".
We might have to harmonize a bit, but for instance "2.3. Identifying the Client Instance" might very well hold information about devices or at least the software running on it (that's the point of client software attestation to be discussed in #44)

We don't always know in advance whether it will be a RO or an end-user only, so the proposal isn't always applicable.

[Denisthemalice]

I was indeed referring to "2.2. Requesting Subject Information" which has no relationship with "2.3. Identifying the Client Instance".

This means that your arguments do not apply to section 2.2. and, by implication, that my argumentation currently remains valid.

[fimbault]

Well, I take the point in consideration but I don't think we should base our reasoning on the structure of sections, which can change