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

[Francis Pouatcha <[e-mail]>]

On Mon, Jul 20, 2020 at 10:30 PM Tom Jones <[e-mail]>
wrote:

> that sounds like a good start - some points.
> 1. Many of the statements, like the RO owns the data, are technically or
> legally incorrect, but i think we know what you mean. - controls access
> might be more appropo.
>
OK.

> 2. the user may be a delegate of the RO and have some sort of token that
> proves his authority. It would be interesting to know if that token is in
> scope.  If not perhaps I can find someone else to own it.
>
Talking Grant Negotiation, the happy path assumes that the User/Client is
not in possession of an AuthZ.

- If a Client is in possession of an AuthZ he assumes valid, he can
directly proceed with step (6) ServiceRequest(AuthZ)
- If the client does not the authorization requirement, we could allow the
request in "step (1) ServiceIntent" to present an existing AuthZ to the RS.
If RS judges this AuthZ to be sufficient, the returned AuthZChallenge can
contain an Exemption from further Authorization, instructing the Client to
proceed with "step (6) ServiceRequest(AuthZ)".

Peace ..tom
>
>
> On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha <fpo=
> [e-mail]..org <[e-mail]>> wrote:
>
>> Hello Dick,
>>
>> Here is (in a new thread) the promised attempt to define terms of
>> interest in the GNAP protocol.
>>
>> 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.
>>
>> Resource Owner (RO) - the party that
>>       - owns a Resource,
>>       - relies on the services the GS to manage access to that Resource
>> and
>>       - relies on the services of a RS to hold the Resource and guard
>> access to that Resource.
>>
>> 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. 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 the release of a Resource he owns to a
>> 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.
>>
>> This dictionary is supposed to be the base for further discussions that
>> will allow us to provide each term with just enough description to reduce
>> ambiguities and misunderstandings in further exchanges.. I intentionally
>> omitted the specification of the type and nature of each party (For example
>> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
>> in proper subsections.
>>
>> Comments are welcome.
>>
>> Best regards.
>> --
>> 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/