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

Tom Jones <> Fri, 24 July 2020 05:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C96C43A0C13 for <>; Thu, 23 Jul 2020 22:29:00 -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 7SrNPsD-AEnz for <>; Thu, 23 Jul 2020 22:28:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D27DE3A0C0F for <>; Thu, 23 Jul 2020 22:28:58 -0700 (PDT)
Received: by with SMTP id z23so1582363ood.8 for <>; Thu, 23 Jul 2020 22:28:58 -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=mM5h/gu6ghZ8sWC37GIFeq5LrxKCO+lWPRJOtujcy90=; b=uWC9KONku3O+Mamxnbr452rCsPEIDF+RLlwByNaiwH7m+/gHqDm14mTuMoDDFYpLD/ ogpwXOqmArtnzNTYMUZhAnm2IDGXgAm5ic1BZZNtLkPGqzXWfC8CT4XLcIK2UExAFXMc w7icGBh4UBatW/kP9ECcdHdSxtKrXkHCn19J5tiLI2W/LgwTmsZHHHqLps0nZzFycAqY zgx1hUsxMtPC7OZ4nq5ogjEf1LyFmOM18RVTq2olkC850wrdnZIdRf1Iz3/ZwKBtdYvr ZTpS/MCnhnS0omYoO3jpJ9xBER5Ul523g/DZhCUUc1D81jbzyB/1Vsg7ntxkO2Qot7cV IkiQ==
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=mM5h/gu6ghZ8sWC37GIFeq5LrxKCO+lWPRJOtujcy90=; b=eI0bKjp4WrqjSgAMNiG1TxX8oHaUb9Qfk57Ic2SGowfpm4F8GukWFZ7LxNgmM5bsfg RihHxmeBKsL0Zim5vRRssI48cuFhRceBtGOwvc+V6hN02xCjNEBN5snYkzJo2cGmBilh F4TPogKRHCYy89PvxRaZ3e7X1+obO8BoOLSdq6ebUQM0IDAqrNqX2hsHE105eZBS29BJ rUMM41vF/mXQcnMrQeLG0LtYWp91jlpDrgWqlzDfXWGGwEUpP3VeD9EQD0y97m+lQrKa 8g/GYn/6+hmCPf1TjAGngFpcsZ95WDlPaSe5iRQYgI33jSGyoek4TniT9rrPiS3aZ8Ot aadA==
X-Gm-Message-State: AOAM530ObjKy/92fmRpURPFGtC+oHZSB7JM6gpJLICdsF8KlKte4LfpW kPDbQLBX7A8+WsVGacw2wrjWzpYN7jILJRyTHS8=
X-Google-Smtp-Source: ABdhPJwbHrzp5BcbGxH872Xi3+i1mXBda79oMoV6O5tHprvrQgYb6dRnvICAURqjfzfXaGxTNqchSiJPRmzoVCSJXy8=
X-Received: by 2002:a4a:dfb5:: with SMTP id k21mr7705756ook.27.1595568537818; Thu, 23 Jul 2020 22:28:57 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tom Jones <>
Date: Thu, 23 Jul 2020 22:28:46 -0700
Message-ID: <>
To: Francis Pouatcha <>
Cc:, Dick Hardt <>
Content-Type: multipart/alternative; boundary="000000000000e95a8305ab293f58"
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: Fri, 24 Jul 2020 05:29:01 -0000

i generally like this - i guess. you decided to drop "claim" from the list?
that is probably for the best. Claims certainly can come from the resource
one minor suggestion resource is data or service.  (nit - a piece of data
is called a datum)

I must object to the statement that the resource owner actually owns the
resource. That is demonstrably untrue in all the systems I work on. It is a
holder-over from microsoft Sharepoint where it meant the business owner. It
has never meant the actual data owner. Then Sharepoint goes to the extreme
of claiming to be the resource owner, but it never actually sets the acls
which give the access. So it never met the conditions of being an RO. The
Sharepoint system rapidly became unmanageable by the very business owners
that were meant to control the access. It is not a good model to follow. I
would be much happier if we stopped calling it a RO, but if we are stuck
with that at least say that the RO controls access rather than perpetuate a
Peace ..tom

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