Re: [GNAP] generic HTTP resource type

Adrian Gropper <> Tue, 27 July 2021 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88DE53A1251 for <>; Mon, 26 Jul 2021 19:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iJy-q7Q26IS6 for <>; Mon, 26 Jul 2021 19:31:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6D193A124D for <>; Mon, 26 Jul 2021 19:31:49 -0700 (PDT)
Received: by with SMTP id a201so18194549ybg.12 for <>; Mon, 26 Jul 2021 19:31:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/xndgtC6ymF1QnW+3D0Je/BJpXPIo7/0KNANC8zGGa0=; b=o8v+tihryi+GkcL2pl0zXdan4hwSiUfXRlUH3LhalNMY/ncw1ejQl6CmSDD8wcSHMS hQWfkj8L9hOK9XcBsLHbHLPls9XSDH+yZjytwLHqzAsnPmQNtjtA3Acx5FYNywwtzn+p 9vu9598d271yjZkOzrBchuHg/5Fz4+R1wfmyY4U6Ih6TfCFWVnmKXswX2D+kFeJGJ4vn OQMCutKp2zLCFuLKYmNJejS8NJq/sFRax8SKpCAfSWeXXoG5mZEtTFRvjMJAj5BoEEUK RMf8eIfDW2Bwzh64bCn7Ek8MBBgs3Mdbpe95J22okFP3Lre7Xij+g1qpZsHsN5IPyWQQ ympw==
X-Gm-Message-State: AOAM531YXtmGCKRzz+G8ILcfsrvOyoE35WtHQMp7thNFZLdLKSDgnHQh QM/yW6qJ04bLZ34JIvJONyLbNypl4o7ktGs47h7h4tQ6
X-Google-Smtp-Source: ABdhPJwqk3a2rFlTYKSqhrPDCUFZTnG4s6SzqC2hXQwkECkumKDQCO9yxJMDZVfy3sSsdxDHIsdiVaDTtpVr3e/ndy8=
X-Received: by 2002:a25:7bc6:: with SMTP id w189mr20197715ybc.160.1627353108564; Mon, 26 Jul 2021 19:31:48 -0700 (PDT)
MIME-Version: 1.0
References: <YP9bhNFEs3YPw1AD@eh>
In-Reply-To: <YP9bhNFEs3YPw1AD@eh>
From: Adrian Gropper <>
Date: Mon, 26 Jul 2021 22:31:37 -0400
Message-ID: <>
To: Jamey Sharp <>
Cc: GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="000000000000f5d0bf05c811ab67"
Archived-At: <>
Subject: Re: [GNAP] generic HTTP resource type
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, 27 Jul 2021 02:31:55 -0000

Hi Jamey,

I don't understand what's being proposed. Mostly this is due to my
inexperience with HTTP APIs, but I'm trying to learn.

In cases of RS-first AS discovery, the end-user might or might not be the
RO. If the end-user is not the RO, then, from a data minimization
perspective, I do not want the client sharing any request information with
the RS. In other words, I do not assume that trusting the RS is the same as
trusting the AS. Therefore, an RS-first request should not require any
authentication. It should just return a link to the AS associated with that

A request to the RS by the RO should obviously require authentication.

A request to the RS that includes an authorization token is not subject to
authentication of the end-user.

What am I missing?


On Mon, Jul 26, 2021 at 9:04 PM Jamey Sharp <> wrote:

> In today's meeting, I asked about applying GNAP as the HTTP
> authentication method for arbitrary HTTP resources, such as static
> files, in the same way that Basic and Digest auth can be used today.
> Justin asked me to share the question here.
> Because the current draft includes RS-first AS discovery using the
> standard WWW-Authenticate response header, it might work for this use
> case as-is, but I think it can be improved.
> First: Am I correct in thinking that two access tokens retrieved from
> the same AS, by the same end user, with the same "access" list, should
> be indistinguishable to the client? Specifically, if a client receives
> two `WWW-Authenticate: GNAP` headers with the same "as_url" and "access"
> parameters, can it reuse the access token it got for the first request
> on the second request, without consulting the AS again?
> If so, I think the WWW-Authenticate "access" parameter is equivalent to
> the "realm" parameter defined in RFC7235 and used in RFC7617 Basic auth.
> (Perhaps for consistency with HTTP auth, it should in fact be called
> "realm" when used in that header? RFC7235 even uses "scope" terminilogy
> to describe it.)
> Without additional provisions, which I'm pretty sure are not currently
> in GNAP, checking for matching realm/access parameters still requires an
> extra unauthenticated request any time the client needs to access a URL
> it hasn't visited before, even if the response turns out to indicate
> that an earlier access token can be reused.
> RFC7617 defines somewhat magic rules for when a client can proactively
> provide Basic-scheme credentials to a URL where it hasn't previously
> seen a WWW-Authenticate header, in order to avoid a round-trip in the
> common case where the same credentials are accepted at similar URLs. In
> theory, GNAP could specify something similar to make RS-first AS
> discovery more efficient, but that level of magic seems dangerous to me.
> The Digest auth scheme in RFC7616 instead allows the server (in this
> context, the RS) to give an explicit list of URL prefixes which accept
> the same credentials, in the WWW-Authenticate "domain" parameter. I
> think that's a closer fit for GNAP, but rather than making it a header
> parameter, I think it's best to fold it into the token's access rights.
> I propose standardizing a definition of a "type" value for the rights
> request that describes HTTP access rights generically, rather than
> describing actions appropriate to a specific API. I think that would
> make GNAP usable anywhere that Basic or Digest auth are currently used.
> It might also enable a wide variety of RESTful APIs and HTTP-based
> standards to use GNAP without needing to define custom rights types.
> Here is a concrete suggestion as a starting point for discussion:
> "access": [{
>    "type": "http",
>    "locations": [""],
>    "datatypes": ["text/html", "image/*"],
>    "actions": ["GET", "PUT", "DELETE"]
> }]
> A resource request must match all fields to be allowed. If "datatypes"
> or "actions" are empty or absent, then all are permitted. (Permitting
> nothing is the same as not granting any rights at all.) The "locations"
> field is required to be present and non-empty though, and might work
> like the "domain" parameter in Digest: "The client can use this list to
> determine the set of URIs for which the same authentication information
> may be sent: any URI that has a URI in this list as a prefix [...] MAY
> be assumed to be in the same protection space."
> This allows a client to request a limited set of methods or access to a
> limited portion of the protection space. It also allows the AS to inform
> the client of exactly which requests it may use the access token on,
> which may be different than what the client requested.
> If I'm reading the current draft correctly, if a client sends an opaque
> resource reference like `"access": "WallyWorld"`, then the AS may choose
> to send back a non-opaque description of the rights granted by the
> returned access token, such as the above example for the hypothetical
> "http" rights type. Is that right?
> I suppose the downside of the AS transforming an opaque reference into a
> full rights description is that the client can't indicate which rights
> types it understands. If a CMS supports a proprietary API for editing
> blog posts, but also supports WebDAV for file attachments, it might not
> be clear which rights type to use, yeah?
> So here's an additional proposal: a client wishing to use this generic
> HTTP rights type should (must?) explicitly request it in the "access"
> rights request (and may also include the resource reference given in the
> "access" parameter of the WWW-Authenticate header, if any). It must
> specify the exact request URL in the "locations" field, and may also
> specify the method it tried to use in "actions". As usual, the AS may
> return a token granting rights to a wider range of locations or methods
> and is recommended to return the actual granted rights.
> I hope that's reasonably clear and would love to discuss this further.
> Jamey
> --
> TXAuth mailing list