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

Francis Pouatcha <fpo@adorsys.de> Wed, 22 July 2020 00:33 UTC

Return-Path: <fpo@adorsys.de>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E63A08EC for <txauth@ietfa.amsl.com>; Tue, 21 Jul 2020 17:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqL1NgccPPrt for <txauth@ietfa.amsl.com>; Tue, 21 Jul 2020 17:33:40 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA023A08E9 for <txauth@ietf.org>; Tue, 21 Jul 2020 17:33:40 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id 88so231491wrh.3 for <txauth@ietf.org>; Tue, 21 Jul 2020 17:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XB8H1HruhbEYCU2oomBUQQ8TUICeGi23Of+ZESJNi+Q=; b=bKLBjtZWlIBpEhAZ2Iph4OdYciQRSDvcgTQU65rt7NgRDuDXXcyYAqFIoi3+07vfID GN5ukz1VB3aigkA6QWJuxMqiHIiKDvVX9o2ASZmWLC1TYgejZm5Lkj2xWRObmtAzSwrW lBnPsfDZ1RS7uQ3fzYsOpkzi0E5LYzDrx3mqQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XB8H1HruhbEYCU2oomBUQQ8TUICeGi23Of+ZESJNi+Q=; b=XnvAmHn1BQCO/6a/Lo4lYokW65fYZzBeuESdvG+UTgdFt2lHLvV1O0oDXDEwuMVZf3 cxx1dDGF5bpi9rb12pMgmKrJEK/tUtIFAEixyv2p144NX9tZxXPmlPtZMJJEoHW9+WZS w9KVs9mMTgqixxtP82edlp+RU2BHK33o7WPkqq5nRfnIlksZNvjFCp0WkFTOnhcpk/LO ff8l+VHuoWbCcnBQbrlXtRk90vCdtjcJhwuuhwsqnVPzFw3QIlRfPSbldFzLTvbnGObI Jct11dTZBcJpczjYm16ZvOUj6NGtcZ00Z8OrhJIwYc4LN4XluwBz067mTing7ry1c2Qy K90w==
X-Gm-Message-State: AOAM531qHKTe0WZOpsFlfNIISG/qxM6vbzF8GsIg3z3FkgVxI3xu8Nxb ar3m3wQNe4TrF0ntBLDpmiXua9h9MAn17Zi6Kj/hIp1N1ek=
X-Google-Smtp-Source: ABdhPJw7n2Q27dxLzsjsYOjtk+BhcTmDZusZtNBi/VL4EHeQC8CifEct4KZyF01sh1bUkukIZYD5SHv0FpVnOr2VoGQ=
X-Received: by 2002:a05:6000:36c:: with SMTP id f12mr20968713wrf.89.1595378018418; Tue, 21 Jul 2020 17:33:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyO2C1E3Sg58CrSVT81t0T3iCTY87tdAx+a8d2A+cNa3nA@mail.gmail.com> <CAD9ie-vMzepgmaP-jUunKSo-chWrGpB230TWgJq7u8Yt-afDxA@mail.gmail.com> <CAOW4vyObyZC7USUqsW_qdDV9Hcpvg9OHKmM1yMEjSUvmjx0UZQ@mail.gmail.com> <CAD9ie-sWn41XDiwyFMcTgV3a8MMESXqf36fNJcTaSYDKwU+LPg@mail.gmail.com> <CAOW4vyNzGG95eNf6RRLf_jgHoQDMJHz8kPF10EENeaAq9vkrVQ@mail.gmail.com> <CAD9ie-vPDMPM8CRid169WsssD0r3dWNqoNCDJcgrxEs+MfvtjQ@mail.gmail.com> <CAOW4vyOjpL3Qoy02uV1dxc+wYir+yh0wWKiaV93OqzRXtk_Sxg@mail.gmail.com>
In-Reply-To: <CAOW4vyOjpL3Qoy02uV1dxc+wYir+yh0wWKiaV93OqzRXtk_Sxg@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Tue, 21 Jul 2020 20:33:27 -0400
Message-ID: <CAOW4vyMgW=3-nrgODnhj-BweWhJgW3WzTJDhSAwdnHFdho6msg@mail.gmail.com>
To: txauth@ietf.org
Cc: Dick Hardt <dick.hardt@gmail.com>, Tom Jones <thomasclinganjones@gmail.com>, Justin Richer <jricher@mit.edu>, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="00000000000012165105aafce40f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/95uBMz12dl0dAO-rqBuUw3p7yCk>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2020 00:33:43 -0000

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 <fpo@adorsys.de> wrote:

>
>
> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>>
>>
>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <fpo@adorsys.de> wrote:
>>
>>>
>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> 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/