Original text:
of client software in the form of access tokens or other information (such as subject information). <del> application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.  Example: a client can be a mobile application, a web application, etc.  Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software).  For some kinds of client software, there could be many instances of that software, each instance with a different key. </del>  server that provides operations on protected resources, where operations require a valid access token issued by an AS. specific interaction mechanisms at runtime. It also is sensible to pre-register client instances when the <del> software is acting on its own behalf, without the need for a runtime </del>  approval by a resource owner or any interaction with an end-user.  In these cases, an AS needs to rest on the trust decisions that have been determined prior to runtime in determining what rights and

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 23be826dff576781855cbc3644dccfea277f16f2 Inspect the deploy log: Browse the preview:
From , account for the many situations in which there is no user -- no person involved in the transaction. Proposal to update the definition (added part in bold) : Client : application operated by or on-behalf of an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.
Since it took us a long time to agree upon the terminology, such a change would be returning back to where we were one year ago while we were defining the terminology. Such a change in the client definition would involve a major change in the architecture model itself. Letting a client operating without the control or the presence of an end-user would leave the door opened to severe security risks. This would allow to skip an important step : getting the end-user consent for contacting an AS to get some attributes and /or some rights included into an access token. The RS would need to be able to distinguish between a "client instance without any user" and a "client instance with an end-user". So such a change in the client definition would lead to changes in the protocol itself. For the above reasons, I disagree with such a change in the client definition (which looks minor, while it is not). Note that, at this time, draft-07 still does not indicate which relationships exist between client instances and end-users, nor how/when these relationships are established by an AS.
I didn't say it is a minor change, it is indeed an important topic, hence the dedicated issue While we agreed on some definitions, those are not set in stone if the WG agrees (cf where we also discuss improvements) Now on the core of your remark : it's not because you don't have a user that you have no consent. Many policies can be automated.
NAME It was always intended that there might not always be a person operating the client instance in real-time, there are several sections in the document that account for this set of use cases. This issue is just aligning the definition with reality, not re-litigating the terminology discussion. As such I'd suggest something more like: Client: application that consumes resources from one or several RSs and receives subject information from an AS, possibly requiring access privileges from one or several ASs. The client is operated by the end-user, or it behaves autonomously on behalf of a resource owner. The distinction here is that when there's no end-user, the client instance is operating on behalf of the resource owner by some pre-negotiated access right based on the identity of the client instance itself. 6749 has the following text for a similar situation:
The proposed definition by NAME seems clearer (even if autonomously could be discussed, I think, to make it more precise : it's autonomous after rules have been defined and validated by the RO)
NAME ; You wrote: A user consent may be given (or refused) once a user notice has been able to be accessible to the end-user so that he can know what kind of usage or processing will be made by the RS with his attributes. Even, if the client can cache earlier decisions, the end-user must be able to make his decision based or not on a cached response. Your argumentation seems to me a bit far-fetched. NAME . You wrote: I found a single case on page 118 in section 12.11 (Client Instance Pre-registration) where the end-user is different from the RO. I would have expected that draft-07 (including this section) would explain the relationships between client instances and end-users and how/when these relationships are established by an AS. Unfortunately, as I already mentioned, draft-07 still does not indicate which relationships exist between client instances and end-users, nor how/when these relationships are established by an AS. Section 12.11 states: This sentence does not comply with the new definition you are proposing. You are proposing : The first sentence is fine with me. The first part of the second sentence is also fine with me: "The client is operated by the end-user". As far as I understand, the last part of the second sentence only applies in the case where the end-user is also the RO. So it does not apply in general. You know that my main interest is not about the use case where the end-user is also the RO. However for that specific case, you know more that I do, and maybe that specific case should be addressed and explained in a separate sub-section.
This relationship is already described, and it is not established by the AS. This has been discussed many times in this very thread. The last part applies in cases where there is no end-user, or to borrow the OAuth 2 nomenclature that is currently copied in section 12.11, the "client acting on its own behalf". I think we want to move away from "its own behalf" and instead embrace the wider definition of "resource owner" that we have in GNAP that we didn't have in OAuth 2. Therefore the language in 12.11 needs to be updated for consistency.
NAME I wrote: You said: If these trust relationships are not established by the AS, how are they established ? This single question demonstrates that the current draft-07 is missing to address this topic. Nevertheless, you wrote: Would you be able to make a text proposal ?
Changed the phrasing in the definition slightly to align with the later discussion better, but looks great overall!

Revised text:
of client software in the form of access tokens or other information (such as subject information).  <ins> application that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.  The client is operated by the end-user or it runs autonomously on behalf of a resource owner.  Example: a client can be a mobile application, a web application, etc.  Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software).  For some kinds of client software, there could be many instances of that software, each instance with a different key. </ins> server that provides operations on protected resources, where operations require a valid access token issued by an AS. specific interaction mechanisms at runtime. It also is sensible to pre-register client instances when the  <ins> software is acting autonomously, without the need for a runtime </ins> approval by a resource owner or any interaction with an end-user.  In these cases, an AS needs to rest on the trust decisions that have been determined prior to runtime in determining what rights and