The text is silent about how / when / if an AS is able to authenticate the end-user

[Denisthemalice]

Section 12.11 (Processing of Client-Presented User Information) states:

GNAP allows the client instance to present assertions and identifiers of the current user to the AS as part of the initial request. This information should only ever be taken by the AS as a hint, since the AS has no way to tell if the represented person is present at the client software, without using an interaction mechanism. This information does not guarantee the given user is there, but it does constitute a statement by the client software that the AS can take into account.

This highlights the fact that the information presented by the client about the end-user is only identifying the claimed end-user and by no way authenticating it.

The following text is silent about how / when / if an AS is able to authenticate the end-user.

Later on the text continues with:

In cases where the AS trusts the client software more completely due to policy or by previous approval of a given client instance, the AS can take this user information as a statement that the user is present and could issue access tokens and release subject information without interaction.

What means more completely ? How may an AS trust the client software more completely ?**

Note that the core protocol does not support any feature that is able to make the difference between a "trusted client instance" and an "untrusted client instance" from an AS point of view.

Anyway, such a case would not comply with the EU Payments Services Directive (PSD2) that took effect in January 2018.

[jricher]

The end user authenticates at the AS during the interaction and authorization process as discussed in section 4.

The means for trusting "more completely" is described in the rest of the sentence you quote above: "trusts the client software more completely due to policy or by previous approval of a given client instance".

[Denisthemalice]

The text of section 4 is about the RO, not about the end-user:

authenticate the RO, through a local account or some other means such as federated login validate the RO through presentation of claims, attributes, or other information prompt the RO for consent for the requested delegation describe to the RO what information is being released, to whom, and for what purpose provide warnings to the RO about potential attacks or negative effects of allowing the information allow the RO to modify the client instance's requested access, including limiting or expanding that access provide the RO with artifacts such as receipts to facilitate an audit trail of authorizations allow the RO to deny the requested delegation

About "more completely", my argument remains: The core protocol does not support any feature that is able to make the difference between a "trusted client instance" and an "untrusted client instance" from an AS point of view, or a "more completely" trusted client.