Subject: [GNAP] client definition

From: Tom Jones <[email-masked]>
Date: Sun, 13 Dec 2020 10:03:54 -0800

This definition is highly use case specific. It leaves out the possibility
of (eg) a self-issued identifier where the RP displays a request to the
user on a web page, the user clicks the button and the result is that a
wallet on the user's device acting as the AS sends an access token to the
RP (which is typically the client in an OAUTH sense.) The underlined part
is often incorrect.

Client

   - Definition: application *used by an end-user* to interact with an AS
   or a RS

suggestion: Client, an application that desires to get access privileges
from a user to resources on an RS, possibly by way of an AS.

Peace ..tom

---

From: Fabien Imbault <[email-masked]>
Date: Sun, 13 Dec 2020 19:42:47 +0100

Hi,

Thanks for the feedback. Highly use case specific seems a bit of an
overstatement, I would say it is the most common case. But I get your point.
We've tried to be more specific on end-user vs RO. In your proposal I guess
the user you're referring to is the RO.

I find the suggested definition a bit convoluted, let's think about it a
bit more.

Cheers
Fabien

On Sun, Dec 13, 2020 at 7:04 PM Tom Jones <[email-masked]>
wrote:

> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Tom Jones <[email-masked]>
Date: Sun, 13 Dec 2020 14:24:27 -0800

It could be the RO or a guardian for the RO so user is the right term.
Peace ..tom

On Sun, Dec 13, 2020 at 10:42 AM Fabien Imbault <[email-masked]>
wrote:

> We've tried to be more specific on end-user vs RO. In your proposal I
> guess the user you're referring to is the RO.
>
>> This definition is highly use case specific. It leaves out the
>> possibility of (eg) a self-issued identifier where the RP displays a
>> request to the user on a web page, the user clicks the button and the
>> result is that a wallet on the user's device acting as the AS sends an
>> access token to the RP (which is typically the client in an OAUTH sense.)
>> The underlined part is often incorrect.
>>
>> Client
>>
>>    - Definition: application *used by an end-user* to interact with an
>>    AS or a RS
>>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 14 Dec 2020 09:02:12 +0100

Ok, thanks for the clarification.
I'll try to think of a new definition with that in mind.

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 14 Dec 2020 10:56:24 +0100

I feel that putting user or end-user into the definition might do more harm
than good.

my suggestion:

application that consumes resources from one or several RSs, possibly
requiring a negotiation of access privileges with one or several ASs.

On Mon, Dec 14, 2020 at 9:02 AM Fabien Imbault <[email-masked]>
wrote:

>>>> suggestion: Client, an application that desires to get access
>>>> privileges from a user to resources on an RS, possibly by way of an AS.
>>>>
>>>> Peace ..tom
>>>> --
>>>> TXAuth mailing list
>>>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Dec 2020 09:55:26 -0500

I think it’s helpful for the definition to go in this direction. 

I do want to push back on it being use case specific though — we are in fact trying to capture these roles more generally by framing them with the relationships between the roles as the primary driver. The negotiation with the AS (as a role) starts with an HTTP request, but from there the protocol is designed to allow branching off to lots of different models if the client supports it. The AS as a role could be fulfilled by several distributed entities, including items running on the user’s device. There are a lot of things that can be supported from that model, and it’s my belief that the self-issued model you’re talking about can layer onto this. 

 — Justin

> On Dec 14, 2020, at 4:56 AM, Fabien Imbault <[email-masked]> wrote:
> 
> I feel that putting user or end-user into the definition might do more harm than good. 
> 
> my suggestion: 
> 
> application that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs.
> 
> On Mon, Dec 14, 2020 at 9:02 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> On Sun, Dec 13, 2020 at 11:24 PM Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
> On Sun, Dec 13, 2020 at 10:42 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, 
> 
> Thanks for the feedback. Highly use case specific seems a bit of an overstatement, I would say it is the most common case. But I get your point.
> We've tried to be more specific on end-user vs RO. In your proposal I guess the user you're referring to is the RO. 
> 
> I find the suggested definition a bit convoluted, let's think about it a bit more. 
> 
> Cheers
> Fabien
> 
> 
> On Sun, Dec 13, 2020 at 7:04 PM Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
> This definition is highly use case specific. It leaves out the possibility of (eg) a self-issued identifier where the RP displays a request to the user on a web page, the user clicks the button and the result is that a wallet on the user's device acting as the AS sends an access token to the RP (which is typically the client in an OAUTH sense.) The underlined part is often incorrect.
> 
> Client
> 
> Definition: application used by an end-user to interact with an AS or a RS
> suggestion: Client, an application that desires to get access privileges from a user to resources on an RS, possibly by way of an AS.
> 
> Peace ..tom
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked]