Re: [GNAP] Terminology - into Github Issues

[Fabien Imbault <[e-mail]>]

+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]> 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
>