Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary

[Francis Pouatcha <[e-mail]>]

Hello Fabian,

On Wed, Jul 22, 2020 at 4:26 AM Fabien Imbault <[e-mail]>
wrote:

> Hi all,
>
> Thanks for that work.
> It would make things easier if we could group the definitions which can be
> generic (without any knowledge of the GNAP architecture) from the terms
> which are dependent on the protocol flow itself.
>
> For terminology, the way it is done in ISO standards is quite interesting
> and we probably could reuse some ideas. The general rule of thumb is to
> reuse definitions when that's possible and re-define only when necessary.
> See for instance
> https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en
> You'll find :
> - a definition
> - potentially some notes (here we can explain how it differs from an
> already existing term used in a different context) and some examples
> - related reference (in many cases, we don't even need to reinvent
> something, as we just need to be consistent with terms already used in the
> community)
>
Good idea.


> Generic definitions :
> - resource, claim, consent, grant, authorization -> seems to me these are
> generic. Why does it matter in the definition that we know which party is
> doing it?
>
Relationship to parties is essential for the understanding of the GNAP
protocol.

- in most cases, those definitions shouldn't be different from other WGs,
> or else we should explain why that is.
> - party : if we refer to roles, we need to define that too.
>
party is defined to help delimitate User, Client, RS, GS, RO from other
terms.

> - grant : I don't get what you mean by "material form of an RO consent".
> What is material?
>
I meant: a Grant is a [materialization/database representation/...] of an
RO consent. GS stores the RO Consent in the form of a Grant.


> Specific definitions :
> - User, User-Agent, Client, RO, GS : all these are specific to the way the
> protocol is specified, so it does make sense to relate to the parties doing
> it.
>
Ok.

- But even then, we need to check whether that specificity is required. I'm
> not sure I agree with your definition of User, though. In 99% of use cases,
> a user is just... a user, i.e. a natural person. Why do we need to make
> this definition so convoluted?
>
Term User is introduced by Dick (see:
https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-1.1). We
am trying to distance it from the RO. As this confusion leads to a lot of
misunderstandings in discussions in the group.

The User-Agent definition seems enough to convey the idea that interactions
> can be done through real users or things.
>
Not so sure. Precision helps reduce misunderstandings in discussions we are
conducting on GNAP.

Best regards.
/Francis


>
> Cheers
>
> Fabien
>
>
> On Wed, Jul 22, 2020 at 2:33 AM Francis Pouatcha <fpo=
> [e-mail]> wrote:
>
>> Hello Dick, Justin, Tom, Denis,
>>
>> Below is a new version of the dictionary includings comments from
>> different threads. Change log includes:
>> - avoided the expression "owns a resource" in favor of the expression
>> "controls a resource"
>> - included the clarification "resource access" and "claim release"
>> - included a clarification User vs. RO
>> - tried to clarify the word User-Agent
>> - added the definition of a Claim
>>
>> Terms
>> =====
>>
>> Party - represents a role in the GNAP protocol flow. A party can take the
>> form of a web service, an application installed on the user device and
>> acting autonomously or the form of a natural person (resp... of an
>> autonomous device) using an application to interact with other parties.
>>
>> Resource - a piece of data or web service
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by a Resource Server (RS) and
>>       - serviced by the RS to a Client, if the Client provides a valid
>> Authorization.
>>
>> Claim - a piece of data
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by the Grant Server (GS) and
>>       - released by the GS to a Client as part of an Authorization.
>>
>> Resource Owner (RO) - the party that
>>       - controls a Resource,
>>       - relies on the services the GS to manage access to that Resource,
>>       - relies on the services of a RS to hold the Resource and guard
>> access to that Resource,
>>       - controls a Claim,
>>       - relies on the services the GS to release that Claim to a Client.
>>
>> Resource Server (RS) - the party that
>>       - holds a resource and guards access to that resource on behalf of
>> the RO,
>>       - services the Resource to the requesting Client, provided the
>> Client presents a valid Authorization.
>>       The RS is generally deployed as a web service.
>>
>> Grant Server (GS) - the party that
>>       - manages access to a Resource on behalf of the RO,
>>       - holds Claims and releases them when consented by the RO.
>>       For each Resource access request, the GS might request the Consent
>> of the RO and produce a corresponding Authorization that is given to the
>> requesting Client.
>>
>> Consent - act of an RO :
>>       - approving access to a Resource, means approval that a Resource he
>> controls can be given to the Client by the RS.
>>       - approving release of a Claim, means approval that a Claim he
>> controls can be included by the GS in an Authorization to be returned to
>> the Client.
>>
>> Grant - material form of an RO Consent. In order not to interact with the
>> RO on each Resource access request, the GS might store the RO Consent in
>> the form of a Grant for reuse.
>>
>> Authorization - externalized form of a Grant as known to the GS and the
>> RS.
>>       - The GS converts a Grant into an Authorization for use in a
>> Resource access request.
>>       - The RS evaluates an Authorization to decide on whether or not to
>> release the Resource to the Client.
>>
>> Client - the party that provides the infrastructure used by a User to
>> access a Resource. The client infrastructure is designed to:
>>       - Receive the resource access request from the User,
>>       - Interact with the RS to discover authorization requirements,
>>       - Interact with the GS to obtain an Authorization to access the
>> Resource,
>>       - Interact with the RS to access the Resource on behalf of the User.
>>
>> User - the party using the infrastructure of the Client to gain access to
>> a Resource or a Claim.
>>
>>
>> Clarifications:
>> ==========
>>
>> User vs. RO :
>>       - the User is the party using the infrastructure of the Client to
>> gain access to a Resource or a Claim,
>>       - the RO is the party controlling access to a Resource or
>> controlling the release of a Claim.
>> In many use cases, User and RO will be represented by the same party (see
>> oAuth2), but GNAP exposes use cases where User and RO are represented by
>> different parties.
>>
>> User-Agent :
>> User and RO are parties that might be represented by a natural person or
>> an autonomous device. In those cases, User (resp. RO) might need the help
>> of an application to interact with other parties. Such an application is
>> generally referred to as the "User-Agent".
>>
>> Feedbacks are welcome.
>>
>> Best regards,
>> /Francis
>>
>>
>> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <[e-mail]> wrote:
>>
>>>
>>>
>>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <[e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>>> well.
>>>>>>
>>>>> Great. Then it is included.
>>>>>
>>>>
>>>> I pivoted to using the term Grant rather than authorization so that it
>>>> included both authorizing access to a resource, and authorizing the release
>>>> of an identity claim.
>>>>
>>>> Perhaps we should not use the word "authorization"?
>>>>
>>> Authorization is currently used to refer to the token issued by the
>>> GSand presented to the RS by the Client. I have no alternative word for now.
>>>
>>>>
>>>> "resource access" and "claim release"
>>>>
>>>> A Grant then covers both?
>>>>
>>> Yes, Great! The word Grant fits best for both. I suggest adding this
>>> clarification to that dictionary.
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>>
>>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>>
>>>>
>>>> Yes, thanks for clarifying!
>>>>
>>>> /Dick
>>>>
>>>>>
>>>
>>> --
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead
>>> adorsys GmbH & Co. KG
>>> https://adorsys-platform.de/solutions/
>>>
>>
>>
>> --
>> 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
>>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/