Re: [GNAP] Terminology - into Github Issues

[Warren Parad <[e-mail]>]

Well said! +1 for using the right medium for collaboration. I too have
found email for a lot of discussions to be challenging to follow and keep
track of important details.

On Sun, Aug 16, 2020, 09:12 Fabien Imbault <[e-mail]> wrote:

> +1 on creating a durable resource for this.
>
> As with the core spec, doesn't mean we can't discuss on the mailing list.
>
> Fabien
>
> Le ven. 14 août 2020 à 17:33, Denis <[e-mail]> a écrit :
>
>> Hello Francis,
>>
>> - 1.
>>
>> The mailing list is the usual way to exchange short information. The use
>> of the wiki should be restricted to long contributions.
>> You are invited to contribute on the mailing list by proposing both a
>> wording and its meaning if a current proposed wording
>> does not meet your expectations and whenever possible with a short
>> rational.
>>
>> Denis
>>
>> We have been having a lot of great suggestions and discussion in the list
>> on terms. As we go on, a lot of knowledge gets buried in the mailing
>> archives. This why i suggest we use the use cases github wiki to:
>>
>> - start compiling discussions on single terms into issues (tickets),
>> - also create a ticket for each use case, either linking the wiki page,
>>
>> The wiki page will be used to hold the last consolidated state of the
>> definition or use case.
>>
>> Using tickets to complement wiki pages will allow us to:
>> - move valuable contributions on each word or use case to the comment
>> section of the corresponding ticket.
>> - allow contributors or visitors to read the summary of what was
>> discussed on a term (resp. use case) before proceeding with additional
>> comments/questions.
>> - Help focus toward reusable content.
>>
>> What do you think?
>>
>> Best regards
>> /Francis
>>
>> On Fri, Aug 14, 2020 at 10:30 AM Justin Richer <[e-mail]> wrote:
>>
>>> +1 for “end user” as the human person, and perhaps “<client> operator”
>>> as the role they play when, you know, operating the <client>. (Where
>>> <client> should still have a more specific name.)
>>>
>>>  — Justin
>>>
>>> On Aug 14, 2020, at 8:23 AM, Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>> Hi Denis,
>>>
>>> Thanks for your feedback.
>>> Comments inline (marked with FI).
>>>
>>> Fabien
>>>
>>> On Fri, Aug 14, 2020 at 12:02 PM Denis <[e-mail]
>>> <[e-mail]>> wrote:
>>>
>>>> Hi Fabien,
>>>>
>>>> Thank you for your inputs, a ball is finally rolling.
>>>>
>>>> An attempt.
>>>>
>>>> I would add upfront: User =  human person
>>>>
>>>> FI : then end-user is clearer if you want to indicate specifically a
>>> human user. One can also create system users.
>>>
>>>> *<Client> = application that requests access to Resource Servers (RS)
>>>> through a Grant Server (GS). *
>>>> Examples: a web server, a browser-based app, a mobile app, an IoT
>>>> device.
>>>>
>>>> A few explanations: "through" does not sound appropriate since it could
>>>> be interpreted as the GS being necessarilly placed between the Client and
>>>> the RS.
>>>>                                       In addition, more than one GS may
>>>> be necessary.
>>>>
>>>> My proposal:  *<Client> = application that requests access to Resource
>>>> Servers (RS) **on behalf of a User by using one or more Grant Servers
>>>> (GS) *
>>>> *Examples: a web server, a browser-based app, a mobile app.*
>>>>
>>>> FI: agreed.
>>>
>>>>
>>>> *GS = computing service that manages the grant lifecycle to a <Client>
>>>> on behalf of a Resource Controler (RC).*
>>>> Note : for privacy reasons, the GS may be issuing grants without
>>>> knowledge of which resources are requested.
>>>>
>>>> I dislike "*on behalf of a Resource Controler (RC)*". The GS may be
>>>> fully ignorant of the existence of the RSs and hence of the RCs.
>>>> In addition, "*grant life cycle*" is undefined.
>>>>
>>>> My proposal:  *GS = server issuing access tokens to a Client after
>>>> successfully authenticating the User*
>>>>
>>>>
>>>> *Note 1: for privacy reasons, the GS may be issuing access tokens
>>>> without the knowledge of which resources are requested. Note 2: a GS is
>>>> able to disclose to a User the User attributes that it manages.   *
>>>>
>>>> FI: I find the new definition less clear. It's not because you don't
>>> know which RS is called that we shouldn't say the decision is made by the
>>> RC.
>>> "grant life cycle" is indeed currently undefined, what i had in mind is
>>> basically the grant flow from the GNAP protocol, possibly also including
>>> revocation etc.
>>> Not sure why Note 2 is important to put here.
>>>
>>>
>>>> *RS = computing service that grants access only if its Resource
>>>> Controler (RC) consents.*
>>>> Note : the consent may involve a human interaction or may be automated
>>>> based on access control policies.
>>>>
>>>> I dislike "*its Resource Controler (RC) consents" *because it may let
>>>> think that a human person always needs to consent.
>>>>
>>>> My proposal: *R*
>>>> *S = server hosting protected resources, capable of accepting and
>>>> responding to protected resource requests
>>>>                                   when access tokens are being used*
>>>>
>>>> FI : that is why I suggested a note to make sure it is correctly
>>> understood. I'm not sure the proposed alternative is clearer.
>>>
>>>>
>>>> *RC = entity which is controlling the access to a protected resource. *
>>>> Note : a RC may be manually operated by a human or delegated to a
>>>> machine, partially or completely.
>>>>
>>>> A RC is not an entity but a function. I would also place the machine
>>>> case first.
>>>>
>>>> My proposal:
>>>> *RC = function tightly coupled with a RS which controls the accesses to
>>>> a protected resource *                        Note : the function may
>>>> be operated either by a machine or by a human person or by some combination
>>>> of both.
>>>>
>>>> FI : your proposition on the note makes it much better. On the main
>>> definition, I'm not sure what you mean by function, as a result I'm not
>>> sure a reader would understand. Why do you need to say "tightly coupled?"
>>>
>>>> *Consent = the process of asking a RC to accept or decline based on a
>>>> grant request presentation, resulting in either a “yes” or “no” consent
>>>> decision.*
>>>>
>>>> I would instead speak of the "User Consent". The User Consent is a set
>>>> of choices among a proposed set of choices. It is not simply a "yes" or
>>>> "no" consent decision.
>>>>
>>>> My proposal: *User Consent = ability for a User, after being informed,
>>>> of choosing to release or not to a RS some attributes contained in one or
>>>> more access tokens*
>>>>
>>>>
>>> FI: this may be misleading I think. The consent is done by a RC (or in
>>> OAuth terms, RO), not the application user.
>>> I agree there may be a combination of consent decisions, but I think
>>> it's important to say that in the end for each individual choice, you do
>>> have a yes/no decision.
>>>
>>>>
>>>> Denis
>>>>
>>>>
>>>> Fabien
>>>>
>>>> On Thu, Aug 13, 2020 at 3:55 PM Denis <[e-mail]> wrote:
>>>>
>>>>> Fabien,
>>>>>
>>>>> IMHO, nothing is wrong with keeping "Client" since it has a wide
>>>>> spread usage
>>>>> ... but only as long as we can agree on a short and a clear definition
>>>>> for it.
>>>>>
>>>>> I can provide the beginning of such a definition: " application ..."
>>>>>
>>>>> If someone could go a little bit further, this would help. :-)
>>>>>
>>>>> A similar argumentation for GS.  It could be used but only as long as
>>>>> we can agree on a short and a clear definition for it.
>>>>> Any proposal ?
>>>>>
>>>>> Denis
>>>>>
>>>>> Hi,
>>>>>
>>>>> Nothing inherently wrong with Client/AS, which has worked for years in
>>>>> the context of OAuth2. The question is to know whether we can build the new
>>>>> protocol with the same concepts and deal with their known limitations, or
>>>>> if we're better off with more adapted concepts less prone to
>>>>> misunderstandings.
>>>>>
>>>>> Verb vs Noun:
>>>>> Problem is that the grant (noun) can only be understood if there is a
>>>>> grant(verb), i.e. some action that grants something.
>>>>> The grant (noun) definition directly derives from the verb :
>>>>> "something granted ..."
>>>>>
>>>>> I personally have no issue even with the fairly convoluted "The Grant
>>>>> Server issues a grant to the Grant Client representing access that has been
>>>>> granted" (except perhaps from the word Client, but that's a different
>>>>> issue).
>>>>> By the way, grant is nothing new, it's used extensively in OAuth2 as
>>>>> "grant types" (whatever that means).
>>>>>
>>>>> Dick summarized well the reasons why he uses GS instead of AS :
>>>>> 1) "grant" is in the working group name (a weaker reason, but still
>>>>> has been approved). Question: would our reasoning if the protocol ended up
>>>>> being called OAuth3?
>>>>> 2) grant = larger in scope than AS (not only authorization), as it at
>>>>> least includes idclaims + other use cases like payment (?) - no consensus,
>>>>> see difference in appreciation between Justin and Dick
>>>>>
>>>>> As for "Client", if most people think it is problematic, it seems a
>>>>> good reason to change if we find a better alternative.
>>>>> Quoting Dick again: "The confusion in my experience usually stems
>>>>> from people working with software that is acting in multiple roles. IE, the
>>>>> software that is acting as a client in once context, is also acting
>>>>> as an RS in other contexts, or even acting as an AS. The other confusion is
>>>>> that people view clients as being the software the user is using --
>>>>> although it may not be acting as a client in the oauth context." and
>>>>> later "I do agree that it is not the best term in GNAP. Primarily because
>>>>> GNAP is a combination of the client from OAuth 2, and the relying
>>>>> party from OIDC."
>>>>>
>>>>> So far there's no consensus however, recent tries: Initiating
>>>>> Application (Denis), Orchestrator (Francis).
>>>>>
>>>>> Cheers
>>>>> Fabien
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> I would be against using "grant" as both a verb and a noun and stick
>>>>>> purely with one or the other. (In the charter the only use of "grant" is in
>>>>>> the verb: "granted").
>>>>>>
>>>>>> Using it as both a verb and a noun will be confusing and less
>>>>>> accessible.
>>>>>>
>>>>>> I think it will be confusing to say "The Grant Server issues a grant
>>>>>> to the Grant Client representing access that has been granted"
>>>>>>
>>>>>> Whether the access takes place via a token being returned and used at
>>>>>> a resource server, or "claims" that are directly returned from the "Grant
>>>>>> Server" I think should be largely irrelevant when it comes to the naming of
>>>>>> the roles.
>>>>>>
>>>>>> In almost all use cases that I have seen the "Grant Server" is making
>>>>>> a policy based decision "to grant" access to requested resource(s). To me,
>>>>>> that is the fundamental operation happening. I think nearly all use cases
>>>>>> can be applied to that, e.g. the GS grants access to
>>>>>>  - identity attributes for the end user
>>>>>>  - verify an identity attribute (e.g. that user is over 18)
>>>>>>  - all users photos at resource server X
>>>>>>  - a single photo with id 12345 at resource server Y
>>>>>>  - resource of type X at any resource server that trusts the Grant
>>>>>> Server
>>>>>>  - call a payment API with specific properties (e.g. amount < 5)
>>>>>>  - call a file storage API
>>>>>>  - call a "contract signing" API with specific properties (e.g.
>>>>>> contract hash of xxx,)
>>>>>>
>>>>>> While "client" is problematic, it does now have wide spread usage, so
>>>>>> perhaps we are stuck with it.
>>>>>> However I agree with Justin and think "Grant Client" makes things
>>>>>> more confusing.
>>>>>>
>>>>>> What is wrong with keeping "Client" and "Authorization Server"?
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial
>>>>>> Technology Limited which is authorised and regulated by the Financial
>>>>>> Conduct Authority ("FCA").. Moneyhub Financial Technology is entered on the
>>>>>> Financial Services Register (FRN 809360) at
>>>>>> https://register.fca.org.uk/.. Moneyhub Financial Technology is
>>>>>> registered in England & Wales, company registration number 06909772.
>>>>>> Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus
>>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.
>>>>>>
>>>>>> DISCLAIMER: This email (including any attachments) is subject to
>>>>>> copyright, and the information in it is confidential. Use of this email or
>>>>>> of any information in it other than by the addressee is unauthorised and
>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any attachments
>>>>>> are virus-free, it is the recipient's sole responsibility to scan all
>>>>>> attachments for viruses. All calls and emails to and from this company may
>>>>>> be monitored and recorded for legitimate purposes relating to this
>>>>>> company's business. Any opinions expressed in this email (or in any
>>>>>> attachments) are those of the author and do not necessarily represent the
>>>>>> opinions of Moneyhub Financial Technology Limited or of any other group
>>>>>> company.
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead
>> adorsys GmbH & Co. KG
>> https://adorsys-platform.de/solutions/
>>
>>
>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>