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

Dick Hardt <> Tue, 21 July 2020 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC27C3A0B65 for <>; Tue, 21 Jul 2020 09:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8P4shDJHyPV for <>; Tue, 21 Jul 2020 09:00:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B1FE3A0B54 for <>; Tue, 21 Jul 2020 09:00:33 -0700 (PDT)
Received: by with SMTP id k13so2988180lfo.0 for <>; Tue, 21 Jul 2020 09:00:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4r9NRCY7A+rY4Q1UeeqNFKLsCbgGWWTdy4a2KE9AOfo=; b=IjjYRQjDQdpOJoTSJ47q6PNbsI8UtdVFnwxPJyAR22tM96UH9zKaNMlh/oFzCCfl5J A3KCr0/KSB0HfTUmN+QLzxMJrw/hfwlpXcF7wQNUSTDoqy2ApjReCBtAzkB6B6DRUg/g zfpJXYiCKjKfc/gL3QoOgxW6PvWtgUc42uinJlJfdSnWHwf+BLwOnzJHURXPr/gN9RVs 7eV8b8BiKjXdN3JZiJ4gPFzXy4kJ/3qgs1FQHDgeW1Xzf4e0wUq8tQTTtpAA1IU7vfnR ooAYHoWsVZFjJ53GCFzFpOn3cU1K/S1Q9aS/e8fzTSMBSCfYp8P3nDDXlm59+c2BytKW 3KeA==
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=4r9NRCY7A+rY4Q1UeeqNFKLsCbgGWWTdy4a2KE9AOfo=; b=BurElsDpyCKnE/Ic8eSdExqjAuNIPSxlfxecClxe3NdoJZE+imYlek1ElNMrLSYiim ZytWq43m5JaaNAIVAGffSzrOfFBv/sqaxcmL5aBDfFl/jhUSqaj0hsSWCL+aywOrICfY 292BRZvFOCGDAa5eOl6lRwwgk60n7wp8p7TJrQmAdEFUNIFUI7Lg32kSnIqIjV20xMa+ p/zsEG+n2t1mCgTeRkwmn5fPZcfRjofspoJ54bMapjJmq/Je+DxMR4taoqOv1MhSCRKy EOs3b9x/FxCoKEOb2j0KcVab7RkVyy3Q28c0fS2jck9raoACKnaSJQkHzHnhz0ML1sKK 5X9Q==
X-Gm-Message-State: AOAM530/A26nuMEcZ4buBwnswpftJDQvOKnsWrBC/35Iy8dA+RB7zyC7 NszL0qMgtQZDbPSf0Mnf88bc+MVCP0km8Mgf6ePXkt/X
X-Google-Smtp-Source: ABdhPJyMmYKERAqOl/4wiAe5wLiAIf7urX4TUai1zVXBNna+VphSVpJaS0kfsm/sWgS30owTw9RzIt/holh+u6aeGgI=
X-Received: by 2002:ac2:5f48:: with SMTP id 8mr403890lfz.157.1595347231637; Tue, 21 Jul 2020 09:00:31 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Tue, 21 Jul 2020 08:59:55 -0700
Message-ID: <>
To: Francis Pouatcha <>
Content-Type: multipart/alternative; boundary="0000000000000905d205aaf5b9a8"
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 16:00:36 -0000

Thanks for putting this together Francis. I like how you have put different
aspects of a definition into separate points. It reinforces the multiple

I don't see identity claims in your definitions. Was that intentional, or
an oversight.

wrt. Registered Client / Dynamic Client - in my experience putting the
definitions together helps a reader grasp all the various terms used.

Curious why you include "party" in the definition. I would not have thought
that had a definition unique to GNAP.

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