[GNAP] Questions from University Student
Leon Brenig <lbrenig@uni-bremen.de> Fri, 19 May 2023 08:21 UTC
Return-Path: <lbrenig@uni-bremen.de>
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 36639C14CEFE for <txauth@ietfa.amsl.com>; Fri, 19 May 2023 01:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.395
X-Spam-Level:
X-Spam-Status: No, score=-4.395 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-1Zt3L6MIUI for <txauth@ietfa.amsl.com>; Fri, 19 May 2023 01:21:50 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBCDC14F75F for <txauth@ietf.org>; Fri, 19 May 2023 01:21:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1684484506; bh=W3a8okj8DMAfJ6qaZiydctmxnkJuBS7mf1I1UkeVefQ=; h=Date:From:To; b=ZAuq2JPqvHVDerNOkLkrZuLbXYmYd82ce1hgngTECp3JqlTmaHbrJdplQkX1pXt8x PgRnqbnX8rzviXsBdeQeTEx443ZhtQpUy42HTtFNCfrjT61/xU39gI1OecQv69mNvq 92+fjZzHBYYhjjfCj8Q6negCSinFUQOOIir/cTRo4W2Ew8rRjFPzmiKJw6CIjiuvTv d4VMtkZ/5ngeB/4P4wOf2ZsK/YjfrKiQwOacaxudR85+2Q3OiRcgkMk9m9LCZpHo1h hMoPeVs1mf4vniK+I1aM3wDN1b0GmAsI7LoEx8Klrkb1zUcrvF5mP+8xlVoka+gJew HTrWBVyd2kJng==
Received: from [IPV6:2003:ca:7f07:5d07:c622:1eae:7827:6948] (p200300ca7f075d07c6221eae78276948.dip0.t-ipconnect.de [IPv6:2003:ca:7f07:5d07:c622:1eae:7827:6948]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4QN0Dp56JpzDCds for <txauth@ietf.org>; Fri, 19 May 2023 10:21:46 +0200 (CEST)
Content-Type: multipart/alternative; boundary="------------FdIm0zO9bTxHJk2vFkO3HFZB"
Message-ID: <e379740e-7114-79be-9f9e-00c7ad31ed4d@uni-bremen.de>
Date: Fri, 19 May 2023 10:21:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
From: Leon Brenig <lbrenig@uni-bremen.de>
To: txauth@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/a42Ox-d_iYoNxOZRcrO61PvuxoQ>
X-Mailman-Approved-At: Fri, 19 May 2023 09:22:06 -0700
Subject: [GNAP] Questions from University Student
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 19 May 2023 08:24:00 -0000
Dear GNAP WG,
my name is Leon Brenig, and I'm a CS Master Student from the University
Bremen. I was tasked to present a comprehensive look at GNAP and after
working through the current draft two questions came to my mind that I
couldn't fully answer:
1.
What considerations have been made regarding the deployment
intensives of the AS infrastructure (and in what time frame do you
expect a significant shift towards using GNAP)?
* My current understanding: Taking steps towards decentralization
paired with having to implement new flexible AS's seems to work
against incentives for current big players, which would slow
down deployment. Is the improved security and usability
(especially for client development) supposed to outweigh this
and/or did I miss important considerations in this regard?
2.
What are the considerations to limit faulty implementations?
* My current understanding: One critic on OAuth2.0 was its
vagueness, quickly leading to faulty implementations. GNAP
provides a lot of flexibility and extensibility, which results
in a lot of freedom in implementations, which could lead to a
similar issue. Are section 13 and 14 partly intended to combat
this issue, and do you consider this to be a possible problem at
all?
I would be very grateful for some insights into your perspectives!
Kind regards,
Leon Brenig
- [GNAP] Questions from University Student Leon Brenig