[GNAP] Two comments on draft-richer-transactional-authz-06

Denis <denis.ietf@free.fr> Mon, 24 August 2020 08:14 UTC

Return-Path: <denis.ietf@free.fr>
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 DA6493A0B6A for <txauth@ietfa.amsl.com>; Mon, 24 Aug 2020 01:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.763
X-Spam-Level: *
X-Spam-Status: No, score=1.763 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.361] autolearn=no autolearn_force=no
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 R_vjC_BCZjbs for <txauth@ietfa.amsl.com>; Mon, 24 Aug 2020 01:14:20 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1833A0917 for <txauth@ietf.org>; Mon, 24 Aug 2020 01:14:19 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d12 with ME id KLEG230062bcEcA03LEGr9; Mon, 24 Aug 2020 10:14:17 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 24 Aug 2020 10:14:17 +0200
X-ME-IP: 90.79.51.120
From: Denis <denis.ietf@free.fr>
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Message-ID: <1cb7c404-7eb2-961b-d2b6-4f907a644597@free.fr>
Date: Mon, 24 Aug 2020 10:14:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------4F2351AC27AED4EBD0000D34"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/y_7qyF8CCFypd6wpDHa79Oy0xZo>
Subject: [GNAP] Two comments on draft-richer-transactional-authz-06
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: Mon, 24 Aug 2020 08:14:22 -0000

Hi Justin,

I will post three emails today which are related. In order to ease 
discussion, this is done using three threads.

First extract:

1.Protocol

This protocol allows a piece of software to request delegated 
authorization to an API, protected by an authorization server /usually/ 
on behalf of a resource owner.

In general, an access token is able to contain data that allows to 
support either ABAC (Attribute-based Access Control) or resource 
authorizations which allow to perform
one or more operations on a data object protected by a RS (i.e. 
capabilities). The data associated with a user or with a client hosted 
by an Authorization Server
may have two origins:

  * they may be /attributes/ granted by the AS itself which has verified
    somehow that these attributes indeed belong to a user or to a client, or
  * they may be resource authorizations (i.e. capabilities) granted by a
    Resource Controller (RC) with which the AS has a close relationship.
    These resource authorizations allow to perform one or more
    operations on one or more data objects protected by a RS.

Proposed rewording:

This protocol allows a client application to use an API hosted by a 
resource server (RS) by presenting to a resource server (RS) access 
tokens issued
by an Authorization Server (AS). These access tokens may contain 
attributes related to a user or to a client application and/or resource 
authorizations
(i.e. allowed operations on a data resource) granted to a user or to a 
client application by the resource controller (RC) of a RS with which 
the AS has
a bi-lateral trust relationship. In addition, the protocol allows a user 
or a client to retrieve the attributes related to a user or to a client 
and/or resource
authorizations granted by the Resource Controller (RC) of a RS to a user 
or to a client.

Second extract:

2.Transaction request

           To start a transaction, the RC makes a transaction request to 
the transaction endpoint of the AS.

This is not necessarily the start of the story. There are two cases to 
consider, one of them is "AS centric" while the other one is "RS centric".

When both the AS and the RS belong to the same domain, a bi-lateral 
trust relationship exists between the AS and the RS.
However, when a RS is anywhere on the Internet, in general there is no 
bi-lateral relationship but only a unilateral trust relationship:
a RS may simply trust an AS for the attributes it issues but the AS is 
unaware of the RSs that trust it. These two use cases should be supported.

Proposed rewording:

A transaction may be initiated by making a transaction request either to 
the transaction endpoint of the RS or to a transaction endpoint of the AS.
The first case applies in general when the client does not know in 
advance which AS is or which ASs are trusted by a RS. The second case 
applies
when the client knows in advance which AS is trusted by a RS and when a 
bi-lateral trust relationship exists between the AS and the RS, e.g. 
because
they are in the same domain.

1) When a transaction is initiated by making a transaction request to 
the transaction endpoint of the RS, the client or the User MAY first 
need to authenticate
         to the RS before being able to perform any kind of operation. 
The client or the User should be able to identify which authentication 
methods are supported.
        This step is called "Authentication mechanism discovery". The 
client or the User should then be able to query the RS about the 
operations that are supported
        by the RS. This step is called "API discovery".

    2) When a transaction is initiated by making a transaction request 
to the transaction endpoint of the AS, the client or the User MUST first 
authenticate to the AS.
        Hence, the client or the User should be able to identify which 
authentication methods are supported. This step is called 
"Authentication mechanism discovery".

Denis

PS. More details follow on the "Authentication mechanism discovery" and 
the " API discovery" using two separate threads.