[GNAP] Concerns with the lack of progression of GNAP after 20 months of work

Denis <denis.ietf@free.fr> Tue, 01 March 2022 11:48 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 0953A3A07D9 for <txauth@ietfa.amsl.com>; Tue, 1 Mar 2022 03:48:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.128
X-Spam-Level:
X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 UDk0570TcRPS for <txauth@ietfa.amsl.com>; Tue, 1 Mar 2022 03:48:48 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BA13A03C9 for <txauth@ietf.org>; Tue, 1 Mar 2022 03:48:47 -0800 (PST)
Received: from [192.168.1.11] ([82.121.202.228]) by smtp.orange.fr with ESMTPA id P0zlnUd0luCn2P0zmnOq9k; Tue, 01 Mar 2022 12:48:46 +0100
X-ME-Helo: [192.168.1.11]
X-ME-Auth: OWU3ZmVkYWM0M2UwZWM1YifxM2Q3ZDk1YiUzNWJiZTM2MiliMTI0N2YxZmQ=
X-ME-Date: Tue, 01 Mar 2022 12:48:46 +0100
X-ME-IP: 82.121.202.228
Content-Type: multipart/alternative; boundary="------------YMe9xZdm09rf8txBSDwwXRim"
Message-ID: <5d89f969-2e67-32f4-e06b-e230453a906f@free.fr>
Date: Tue, 01 Mar 2022 12:48:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-GB
To: "txauth@ietf.org" <txauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/eK27HuOgEFjlaI_6inln0-s7l6o>
Subject: [GNAP] Concerns with the lack of progression of GNAP after 20 months of work
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <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: Tue, 01 Mar 2022 11:48:53 -0000

Hello everybody,

GNAP has four main components : users, clients, ASs and RSs.

GNAP is supposed to describe a protocol. A protocol is a set of rules 
that control the way data is exchanged between computers.
A reader would expect to find the description of the data sent by a 
client to a RS (which are indeed described in ietf-wg-gnap/core-protocol),
but also find how that data *shall be handled by a RS* which is supposed 
to be described in draft-ietf-gnap-resource-servers. Unfortunately,
this is not the case.

The focus has been placed on the "core" protocol, leaving aside the the RS.

The core document (ietf-wg-gnap/core-protocol) has now got more than 400 
issues !

Besides the editors (and the chair), very few members are active and at 
this time it is unlikely that more members will participate
since *the main driving line for the construction of GNAP has been los**t*.

The recent message called "embedding GNAP" got no reply from the WG, 
except one from a co-editor.
IMO, this demonstrates that *GNAP is still a **moving target* *after 20 
months of work.*

Does this mean that all the WG members agree with the very few emails 
that are exchanged or that the WG members are
no longer really able to participate to the discussion since such 
participation would involve a lot of days to get "up to speed" again ?
I would guess that the right answer is the latter.

The core document has still *no security model *and hence its security 
is more than questionable.

The core document is AS centric and hence *the **privacy concerns of the 
users cannot be addressed*. Is this deliberate ?
When the work started, privacy was supposed to be a major concern to be 
taken into consideration, but in practice, this is not the case.

The core document still does not address the general use case.

There are so many options that *interoperability will not be possible*.

*draft-ietf-gnap-resource-servers-01**expired on 13 January 2022*.  We 
are now close to an IETF meeting and no draft is available.

The milestones are outdated and, anyway, are not observed 
(seehttps://datatracker.ietf.org/doc/charter-ietf-gnap/writeup/)

Milestones:

   Jul 2021 - Core delegation protocol in WGLC

   Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to WGLC

   Oct 2021 - Key presentation mechanism binding to the core protocol, detached HTTP signatures, to WGLC

   Oct 2021 - Key presentation mechanism binding to the core protocol, embedded HTTP signature, to WGLC

   Dec 2021 - Guidelines for use of protocol extension points to WGLC

   Feb 2022 - Guidelines on migration paths, implementation, and operations to WGLC

At the next IETF meeting, rather than addressing, /as usual,/ the last 
technical issues that no one or very few people will be able to follow 
or understand,
I would suggest that the editors address the following topics: 
*interoperability*, *privacy *and *security *at a level that will allow 
everybody to understand
the real issues behind these three words and by presenting *a balanced 
view*.

Denis

PS: If we were working within ISO, this WG would already have been closed.