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

Francis Pouatcha <> Tue, 21 July 2020 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CDA33A0CC4 for <>; Tue, 21 Jul 2020 10:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e6lP-ySqHIff for <>; Tue, 21 Jul 2020 10:42:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B2D23A0CBC for <>; Tue, 21 Jul 2020 10:42:47 -0700 (PDT)
Received: by with SMTP id a14so7169972wra.5 for <>; Tue, 21 Jul 2020 10:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=09polVp2S0vYz7zZuMX6pS6dsqJ9t4LKXtkObtiOdqs=; b=V05ciTMQ7kI2nn5UBQ4oNQ14P6N1wPK3B8eKMoLAj3OF+t/sPllINsVOOK8lJmWmI3 Uq2PEUxyu9fwRNwpJLbVecrOEDENMC99AOs4gLKc3ZOSRlAdq9VH8H4F3wr4y5gXJZoI cjJTnnvnKumRzIEVMtyMEltMQLzZnemm4e8h4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=09polVp2S0vYz7zZuMX6pS6dsqJ9t4LKXtkObtiOdqs=; b=CGO+FnyQDYtLKZS2wb4I27SqMgLQylMWdFs9UyXilRBKSdjj+oh9cV2ahQAZX7wYld 3t1Sgp6mnCLYWTjp/NZPOILqmbD36sgioJJ3wcC+UZT5/xmo6iTL4R01KmbGZQf9eI5W HBoytQLIENpWCOxwiYS+4BQGoz9aQFND1rdd3u/zdE3OqytpJlu9i3rqGPuZtyyxS77c hkRr3ahpPxY5iTcl4Av/irQoIe4R/uAqTIHS7L2g9gV5OsW1/G0MjCDSljcD+CK8j1a/ Uy9YDDeqh7D1C1oVbzGc7zn8aPaHT8I98jIS/fDRGLtzQreXjFYIjYbvPke3ncJlAfQ0 xA0Q==
X-Gm-Message-State: AOAM530FBlp4mJulw/2Tv1MxcEEBxnNwi2CwuhKHFmi7PAygMvKdF9Wb kcqu0kRizDCfTLv4mMFXAqLB0htj0v3d1W8u5sCnXQ==
X-Google-Smtp-Source: ABdhPJykwJY5L66I4OTFdAFvejdr/lGCMTo4BeF29PyRVOA4fVDsewWlG16vMF4pjEKNOX32+dVWmDjvrJ9b/CYaycs=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr14850272wrs.283.1595353365327; Tue, 21 Jul 2020 10:42:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Francis Pouatcha <>
Date: Tue, 21 Jul 2020 13:42:32 -0400
Message-ID: <>
To: Dick Hardt <>
Content-Type: multipart/alternative; boundary="000000000000a1cbb005aaf726cf"
Archived-At: <>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jul 2020 17:42:49 -0000

On Tue, Jul 21, 2020 at 12:00 PM Dick Hardt <> wrote:

> Thanks for putting this together Francis. I like how you have put
> different aspects of a definition into separate points. It reinforces the
> multiple aspects.
> I don't see identity claims in your definitions. Was that intentional, or
> an oversight.
The extensive dictionary will surely include more terms.

I limited the list to terms relevant to the abstract sequence for now.
Making an effort to keep the discussion focused on the abstract sequence.

As we are talking authorization, identities are second class citizens,
focus shall be on Negotiating and Obtaining the AuthZ to access a Resource.

> wrt. Registered Client / Dynamic Client - in my experience putting the
> definitions together helps a reader grasp all the various terms used.
Yes, this clarification belongs in the dictionary. Intentionally left it
out here to avoid diverging the discussion.

> Curious why you include "party" in the definition. I would not have
> thought that had a definition unique to GNAP.
I derived this from your subsection "Parties". As all participants in the
abstract sequence are "parties", the word seems too heavy to be left
undefined. Also essential to know which words in the dictionary do not
refer to parties like Resource, Grant, AuthZ, ...

> On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha <> 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

Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG