From nobody Tue Mar 1 04:48:59 2022 Return-Path: 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 6A93D3A0897 for ; Tue, 1 Mar 2022 04:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5kkHO8FlcWSl for ; Tue, 1 Mar 2022 04:48:55 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 F0CC43A0881 for ; Tue, 1 Mar 2022 04:48:54 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id f2so12454364ilq.1 for ; Tue, 01 Mar 2022 04:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JklxEtzj4pkpHBfVv/ZoVfb3bSW9qbFe7M9Mc3SF4hE=; b=bxbLflPtMJt9TB4FJocrUpZDXNgk/cdtQaO12Gf5gg8yIryctvPIgOI3bCgGqv/uD2 JT2h3EzkUQJVy2+KzuFewwbPQk8HKMrsmjYSyfKZlyM3onyEqY3gYJFel+XuDXt7X/Lq BiR/PbeI32xmb2KIaLQ3larmzfNbsjSZxt2pIZNtGX5lvRic7hCg+1DzAcqY+qqEWRKd ZSe8CvkJYi14ATzIOSQsMBBm+l6QZnquaXt5gWLX/4UB9CBC4xOPHc0LVOCYPjhRmiAL Oxgcn68dBZD8KyaYwQ72LloH9Tf9uPAUS3rbhC1sGk8NN70PIZxsi3FRCl2U35MUa4Ra mRxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JklxEtzj4pkpHBfVv/ZoVfb3bSW9qbFe7M9Mc3SF4hE=; b=7IiU1vNeh8ihzJEKntpqBOAiuONN/EYu+oEUhuhNBVHG93hp4Fqsag3XcK6U9tkfs+ DmRdks/PdujzEpjpDrxcty2og+Av66XsjVxlc5p08Jlg+YBnkcrST/OzGgqIC/yqM/U3 rgPA1hO8XcBR5qcZkdLiiYjPmF5Q4MeFfPXt2XD5Rjga5Rnz9kPlBS8n02ucAv+tVxaa rzLpbygxG1f8rx575RaMhOirUXlD9VP4XbPcVvNRqAPTaKLm0gkN8NP0a/Fpke1B8wBe 782GJL3sRHfFj7CKuRFmrkGnciq1tXwW2BUf/bdgg3rFHfBUiCivJgWiIue/ICTRaMcE Owfg== X-Gm-Message-State: AOAM533d590eP6LQPJ5Nn0beDi++YvUU+2PbAmBRpVbgRgvMys7A47Pm yRJziA3i64Gn7ZhS6zMLYrc4OIw2yPkYvJcEVuk= X-Google-Smtp-Source: ABdhPJw0ctQuAk6e26/BgPSyjCgnNYE2GVthalJA/WOfc5tSm1hZq12kVLclqjhsE18XroVIdGoeO86LBHU/cNTJcTo= X-Received: by 2002:a05:6e02:1585:b0:2c2:5b2c:e3e5 with SMTP id m5-20020a056e02158500b002c25b2ce3e5mr24731475ilu.76.1646138934007; Tue, 01 Mar 2022 04:48:54 -0800 (PST) MIME-Version: 1.0 References: <5d89f969-2e67-32f4-e06b-e230453a906f@free.fr> In-Reply-To: <5d89f969-2e67-32f4-e06b-e230453a906f@free.fr> From: Fabien Imbault Date: Tue, 1 Mar 2022 13:48:42 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000699c6005d9279668" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2022 12:48:58 -0000 --000000000000699c6005d9279668 Content-Type: text/plain; charset="UTF-8" Dear Denis, Sorry I have to say this, but repeating your misconceptions don't make them true. That's currently not helping anyone going forward. The editors and chairs welcome anyone with helpful contribution. Already the spec had many great improvements, from many outstanding individuals cited in the text. Including on security and privacy. We are now stabilizing the core draft and focusing on real world implementations to demonstrate the value and interoperability. Best regards, Fabien (speaking only in my own name) On Tue, 1 Mar 2022, 12:49 Denis, wrote: > 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 (see > https://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. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000699c6005d9279668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Denis,

Sorry I have to say this, but repeating your misconceptions don't = make them true. That's currently not helping anyone going forward.

The editors and chairs welco= me anyone with helpful contribution.=C2=A0
Already t= he spec had many great improvements, from many outstanding individuals cite= d in the text. Including on security and privacy.
We are now stabilizing the core draft and focusin= g on real world implementations to demonstrate the value and interoperabili= ty.=C2=A0

Best regards,<= /div>
Fabien (speaking only in my own name)




On Tue, 1 Mar 2022, 12:49 Den= is, <denis.ietf@free.fr> wrote:
=20 =20 =20

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-p= rotocol),
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 "c= ore" 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), ver= y 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 lost.

The recent message called "embedding GNAP" got no reply fr= om 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&qu= ot; again ?
I would guess that the right answer is the latter.

The core document has still no securi= ty 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, pr= ivacy 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 intero= perability will not be possible.

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

The milestones are outdated and, anyway, are not observed (see htt= ps://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, detac=
hed HTTP signatures, to WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol, embed=
ded 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: int= eroperability, 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.

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth
--000000000000699c6005d9279668--