[GNAP] API discovery

Denis <denis.ietf@free.fr> Mon, 24 August 2020 08:19 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 BAB1C3A0B72 for <txauth@ietfa.amsl.com>; Mon, 24 Aug 2020 01:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.764
X-Spam-Level: *
X-Spam-Status: No, score=1.764 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, URIBL_BLOCKED=0.001] 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 iXUDAJMbZrPz for <txauth@ietfa.amsl.com>; Mon, 24 Aug 2020 01:19:41 -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 98D5B3A0B71 for <txauth@ietf.org>; Mon, 24 Aug 2020 01:19:40 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d12 with ME id KLKe2300T2bcEcA03LKeQS; Mon, 24 Aug 2020 10:19:39 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 24 Aug 2020 10:19:39 +0200
X-ME-IP: 90.79.51.120
To: "txauth@ietf.org" <txauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <0cf1f1e6-654b-26e4-2961-27ee4e957f33@free.fr>
Date: Mon, 24 Aug 2020 10:19:38 +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="------------0006CBCD9876890801C297A8"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/3UsUlk4Ojjj6YiMz99y6XZ2WlKY>
Subject: [GNAP] API discovery
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:19:43 -0000

To the list,

**A discovery mechanism should be usable to discover which actions are 
possible on the RS.

This can be seen as a means to implement some aspects of the level 3 of 
the Richardson Maturity Model (RMM):
HATEOAS (Hypermedia as the Engine of Application State) but combined 
with access control, i.e. knowing at the same time
which actions that can be done and the access control characteristics 
associated with these actions which is an aspect
that is not addressed in HATEOAS.

Such an API discovery mechanism could be used before or after 
authentication has been achieved on the RS.

If the API discovery mechanism is used before authentication has been 
achieved, the RS might indicate that no operation is available
at this time which would means that the available operations will only 
be disclosed once authentication has been achieved.

See the simple example from : https://en.wikipedia.org/wiki/HATEOAS 
which is using a GET request.
It is important to notice in that example that the allowed actions that 
are possible varies dynamically as the state of the resource varies.

Using an appropriate HTTP OPTIONS request, the client (or its User) 
should be able to know:

  * which actions that can be done (i.e. which methods are available on
    which data objects), and
  * the access control characteristics associated with each of these
    actions (i.e. which ASs are being trusted by the RS
    and what should be incorporated into access token(s) in terms of
    attributes types (and optionally attribute values)
    or in terms of capabilities (i.e. permissions granted by a Resource
    Controller).

In the case where the request is made on behalf of a User, this 
information should be usable by the User Agent of the client in order to 
capture the User Consent.
The selection made by the User should then be sent back to the client, 
so that the client would be able to request the appropriate access 
tokens from the appropriate ASs.

Then after, at every step further in the processing of a transaction, 
the client would be able to issue another HTTP OPTIONS request.

A client supporting JavaScript would be able to take a full advantage of 
such an approach. Using an appropriate format indication in the HTTP 
OPTIONS request,
it would even be possible to get a response directly processable under a 
client supporting JavaScript.

A less ambitious approach would be to tell to the client the access 
control rules that apply once an operation has been selected
(instead of before the operation has been selected).

Denis