Re: [GNAP] generic HTTP resource type

Jamey Sharp <> Sun, 01 August 2021 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 816153A14B1 for <>; Sun, 1 Aug 2021 15:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zevDBn-Hv60a for <>; Sun, 1 Aug 2021 15:08:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D98C23A14AC for <>; Sun, 1 Aug 2021 15:08:28 -0700 (PDT)
Received: by with SMTP id m10-20020a17090a34cab0290176b52c60ddso22011185pjf.4 for <>; Sun, 01 Aug 2021 15:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to; bh=sb50A1Tw6/FJ7FJU0eR4g/0QsIXjC3yiA4wPe01goeQ=; b=f6Vffhmit1b3SPi5MOhOf6Txw258lV+CUKPhY200B3Cb5QRI89OexzVPfpHOgrll0d aulkB5F/KoYRns/1bxKcbQf/j5keht5iLWL4N3g7m9r01Wg5zS5f+YyjsDqNar2MS1jG +5EQ+1YLVqjv1DMRVK2GG+K+0zhAKRHIGfatQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to; bh=sb50A1Tw6/FJ7FJU0eR4g/0QsIXjC3yiA4wPe01goeQ=; b=VmrntBq8Oy0npfotAfKjEFbbqG7VFdymHqI3g+B6OfvIGQu05+lS63X0l90ZXuCqoM qH9fMePmDpF7xoE7J/au7fD+BqAslN6TvtUkeufB36ngh2y6XSatL2wfJPuZfdXehMha CuvrOgW5s3PSa6Iph585qsiKhGYgqHOzN+VZ3U6KLSgpV5BnxoZKIkfuROQu5ZeqKHJO JeYQanU3TwSYLgx3rNbv+4lDKzl80J172zJeFeAqP41ZNH6QMnGn8dcPIzwCkW2EqAqh 6RoFwRMZb/0Hmm+KTdHp/08EZIGkTzGKQFpmplMhluxC9JxJxlh0jkOdFUVhSPtpu5Fk Lgeg==
X-Gm-Message-State: AOAM53269eGZ7iRUkwLUcf0igbift3cYcLezidMSKkmgy3H7Iam8DE8k 8IFblMILgz3MBpHzRoTgAUj9Gw==
X-Google-Smtp-Source: ABdhPJyoDIhbPuRsHQ1UDLAkWBqyoxLzwM+t/jJtUyHzZ+8FoI/SHz3XIUV04oWWYALlnavCEuHXqA==
X-Received: by 2002:a63:4e51:: with SMTP id o17mr3834890pgl.126.1627855707307; Sun, 01 Aug 2021 15:08:27 -0700 (PDT)
Received: from eh ( []) by with ESMTPSA id t8sm754708pja.41.2021. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Aug 2021 15:08:26 -0700 (PDT)
Received: by eh (sSMTP sendmail emulation); Sun, 01 Aug 2021 15:08:25 -0700
Date: Sun, 01 Aug 2021 15:08:25 -0700
From: Jamey Sharp <>
To: Justin Richer <>, Fabien Imbault <>
Message-ID: <YQcbWVgc0TKSynQ2@eh>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <> <>
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: Sun, 01 Aug 2021 22:08:34 -0000

Hi Justin and Fabien! Thanks for your kind responses. You both provided 
helpful information about the process and requirements, but I'm less 
clear on what my next steps should be. In the interests of trying 
something, here's some text that I propose as a starting point for an 
appendix in the core draft. I welcome edits or complete rewrites.

Many resources have simple access policies which map well onto standard 
HTTP semantics. For example, authorization for WebDAV can generally be 
defined in terms of a WebDAV collection and a set of HTTP methods which 
the client instance is permitted to apply to members of that collection. 
(NB: I haven't touched WebDAV in years, I have no idea if this is a good 

This resource type supports such generic HTTP access policies. HTTP user 
agents which implement RFC7235 MAY support GNAP with this resource type 
as an alternative to other generic authentication schemes such as Basic 
(RFC7617) or Digest (RFC7616).

type (string): "urn:ietf:gnap:http"

locations (array of strings): URL prefixes to which the client instance 
MAY issue requests using this access token without first sending a 
preflight RS-first AS discovery request. This array MUST NOT be absent 
or empty. Each URL in this array MUST use a scheme of "http" or "https", 
MUST be an absolute URI, and MUST have a non-empty path component.

actions (array of strings): HTTP methods which the client instance MAY 
use at the RS. Per RFC7230, the request method is case-sensitive. If 
this array is absent or empty, this access object permits all methods.

If an access object permits a request, that is not a guarantee that 
issuing that request to the RS will succeed. However, if an access 
object does not permit a request, then the client instance MUST NOT 
issue that request using that access token without first performing an 
RS-first AS discovery.

A client instance without any prior knowledge of the resource types in 
use at an RS MAY attempt to use this generic HTTP resource type during 
GNAP requests to the AS. An AS MUST NOT implement a resource type with 
the same value of "type" as given here but with different semantics.

A client instance which performs RS-first AS discovery SHOULD be 
prepared to accept an access policy from the AS which uses this generic 
HTTP resource type.

An RS which uses this resource type SHOULD respond to RS-first AS 
discovery with an `access` parameter which the AS is configured to 
expand to an access object of this type. If it does so, the AS SHOULD 
return an access list containing both the resource reference given in 
the `access` parameter as well as the full access object of this type.

Returning the full access object enables the client instance to avoid 
issuing preflight RS-first AS discovery requests for any request that 
the access object permits.

If the client later performs RS-first AS discovery again and recieves 
the same `as_url` parameter in response, then returning the resource 
reference in the access list enables the client instance to discover 
that it has a valid access token for that resource reference, so it 
doesn't need to query the AS again.

I kind of want to add something like this as well, but started confusing 
myself about what the client can and can't do with it:

datatypes (array of strings): Media types or ranges which the client 
instance MAY send in request bodies. The syntax for each string is given 
by the "media-range" EBNF production in RFC7231. If this array is absent 
or empty, this access object does not permit request bodies. To allow 
any request body, use a media range of "*/*".

Note that if an access object permits the "POST" method for resources 
which are expected to be the target of HTML form submissions, then that 
object likely needs to list "multipart/form-data" and/or 
"application/x-www-form-urlencoded" as permitted datatypes.

Thoughts and feedback?