From nobody Sun May 9 11:33:54 2021 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 566B43A19E5 for ; Sun, 9 May 2021 11:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 JmFbE5kilRt9 for ; Sun, 9 May 2021 11:33:49 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 04D723A19E4 for ; Sun, 9 May 2021 11:33:48 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id z1so4280437ils.0 for ; Sun, 09 May 2021 11:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X6waPKyEzr6esxVQPXwRYhuy4DJToOw5sm1nzbqzVhY=; b=tzTRiJKXOu24JTeU3FkmPgFN7WLhqu5tfjzMxtjo8AQ1cRGNhWi48MpuoVVyUahQ/E 5NhijvXU1zIFoBiNMEvDXE/JXGzDZ7V681YOGFD3kY/wf/JJOPVqd5l82RfjwFypVYgN 5Ip9i+TaafEN7+o14kQpF8LQ2bGQtb3fJjHk7PHW5mAWP56QsC+61pIG9O4MG7lOTofr 3Mzgwdke/QJYCm7ypIUNOwCNRVmi+CTSypvl12wlntZeNyJybOhYToMNOyVoU7X1ECg+ 5e2HkKoeVIpSNWbfA0qmIto6DtAnL3qDRX3iCCqVaK6pKNC8r5qRaE8hH4kLauj4bdmR 9Fiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X6waPKyEzr6esxVQPXwRYhuy4DJToOw5sm1nzbqzVhY=; b=bL5M98Tj9oF3q2/SypWMOBzbE6tEQxw+jvfZ0t+nNADqkos7Z/wmqlbOBVgrJVD3Oz vojRDbrrivfUT9UQ+ZKPXcznUyUyjAq+gKXMl/aH9XfS+cCbHyw+fq2Z10vsBg5j5022 puYw/R7FLRRn3x3W1pF5srHiynxWtN5z0n8OQFt48hYcu1fNNs9MZb9jDPGgsX5s60LZ pJMOOumxVbiYzcZxvU34ywyyFtgHVLoUxQ7W23HOf9/de8R2Rw77cVI8u9x1va3wrWcF B+ec+nW+hk0mc6kyKFSAevkyEVMotrHTPSJZThBiUQRi1Z4PO9v9REhUS6bpo+emFqSb ceDA== X-Gm-Message-State: AOAM532CfaUS9j8OKVrSzYwmr9RfqgsZErEBTVz4cCI3wMvcPTRyVDba EPmD8LqAOfsLoSFQrAxe95dpswGMblg91q86RIw= X-Google-Smtp-Source: ABdhPJwJMi4WHkLUUrZJdOuW3jyP40ybJHOeLEV2phHtoAREDLMZeW9it2V+fZpnT17TwU+eq9fk6xsBQOAHhujpUy0= X-Received: by 2002:a92:6a04:: with SMTP id f4mr17532897ilc.289.1620585226699; Sun, 09 May 2021 11:33:46 -0700 (PDT) MIME-Version: 1.0 References: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> In-Reply-To: <8517AD16-92CD-7743-92CC-D8ABC4DAAEC9@hxcore.ol> From: Fabien Imbault Date: Sun, 9 May 2021 20:33:35 +0200 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c408f905c1e9e626" Archived-At: Subject: Re: [GNAP] Resource Servers draft 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: Sun, 09 May 2021 18:33:53 -0000 --000000000000c408f905c1e9e626 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, A comment on access token formats: I don't think we should define our own format, but we can reference other documents such as https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-jwt and the references to macaroons, biscuits. The rest I believe makes good issues, most of which should be quick to fix. Cheers Fabien On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer wrote: > Hi Editors, > > > > Here=E2=80=99s a bunch of comments to the latest version (Editor=E2=80=99= s Draft as of > today). Please respond with what is easy to fix, and what I should open a= n > issue for. > > > > Thanks, > > Yaron > > > > - Abstract: better use more concrete terms than "piece of software". > Even if this creates a dependency on the Terminology section. > - Typo: by (AS). > - "client-facing discovery mechanism" - I'm not seeing any > client-facing protocol in the document (and it wouldn't belong here an= yway). > - Terminology: include a reference to the Terminology section of the > Core doc. > - Access Token Formats: IMO we should specify a minimal, generic > format in an appendix, as a non-normative starting point for developer= s. It > would be better than having each implementation make its own mistakes. > - Macaroons, biscuits, other baked goods: add a reference. > - AS Discovery: why do we need a "well known" URI? Either we use GNAP > Core to pass the AS address to the RS, and then we could pass a full U= RI, > or we don't, and then how does the RS even know how to find the AS? > - Protecting RS requests to the AS: the RS, by definition, owns > resources. This means that it needs to have a persistent identity, in > addition to the (ephemeral) keys being presented. Otherwise (especiall= y > with TOFU registration) we could easily have Resource Servers squattin= g on > other people=E2=80=99s resources. It is very hard to manage the mappin= g of RS to > resources if we don't have such a persistent identity. > - Token Introspection: it is not clear to what depth we are defining > the API: is it only the existence of the "introspect" endpoint? Or do = we > define a minimal set of standard attributes that need to be returned? = The > API would not be useful for interoperability unless we define some of = the > returned attributes. At the very least: "active". > - "client instance's request" - should be "Resource Server's request". > - And we should add: the AS MUST validate that the token is > appropriate for the RS that presented it, and return an error otherwis= e. > - Typo: internal link to "token format". > - IANA Considerations: the "well known" URL should be registered (BTW, > it's a well-known *URI*). Also, please list the registries that we nee= d to > establish. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c408f905c1e9e626 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,=C2=A0

A comm= ent on access token formats: I don't think we should define our own for= mat, but we can reference other documents such as=C2=A0= https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-jwt= and the references to macaroons, biscuits.

Th= e rest I believe makes good issues, most of which should be quick to fix.

Cheers
Fabien

On Sun, May 9, 2021 = at 4:00 PM Yaron Sheffer <yaron= f.ietf@gmail.com> wrote:

Hi Editors,

=C2=A0<= /p>

Here=E2=80=99s a b= unch of comments to the latest version (Editor=E2=80=99s Draft as of today)= . Please respond with what is easy to fix, and what I should open an issue = for.

=C2=A0

Thanks,

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

=C2=A0<= /u>

  • Abstract: better use more concrete terms than "p= iece of software". Even if this creates a dependency on the Terminolog= y section.
  • Typo: by (AS).
  • "client-facing discovery mechanism" - I'm not seeing an= y client-facing protocol in the document (and it wouldn't belong here a= nyway).
  • Te= rminology: include a reference to the Terminology section of the Core doc.<= u>
  • Access Tok= en Formats: IMO we should specify a minimal, generic format in an appendix,= as a non-normative starting point for developers. It would be better than = having each implementation make its own mistakes.
    • =
  • Macaroons, biscuits, other baked go= ods: add a reference.
  • AS Discovery: why do we need a "well known" URI? Eith= er we use GNAP Core to pass the AS address to the RS, and then we could pas= s a full URI, or we don't, and then how does the RS even know how to fi= nd the AS?
  • Protecting RS requests to the AS: the RS, by definition, owns resources. T= his means that it needs to have a persistent identity, in addition to the (= ephemeral) keys being presented. Otherwise (especially with TOFU registrati= on) we could easily have Resource Servers squatting on other people=E2=80= =99s resources. It is very hard to manage the mapping of RS to resources if= we don't have such a persistent identity.
    • Token Introspection: it is not clear t= o what depth we are defining the API: is it only the existence of the "= ;introspect" endpoint? Or do we define a minimal set of standard attri= butes that need to be returned? The API would not be useful for interoperab= ility unless we define some of the returned attributes. At the very least: = "active".
  • "client instance's request" - should be "Resou= rce Server's request".
  • And we should add: the AS MUST validate that the toke= n is appropriate for the RS that presented it, and return an error otherwis= e.
  • Typo: i= nternal link to "token format".
  • IANA Considerations: the "well known&q= uot; URL should be registered (BTW, it's a well-known *URI*). Also, ple= ase list the registries that we need to establish.
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000c408f905c1e9e626--