Re: [GNAP] Terminology

[Denis <[e-mail]>]

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] 
> <mailto:[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.
>
>