Re: [OAUTH-WG] Namespacing "type" in RAR

Dick Hardt <dick.hardt@gmail.com> Fri, 17 July 2020 17:25 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB93A092E for <oauth@ietfa.amsl.com>; Fri, 17 Jul 2020 10:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 eBC0BCd9g6M5 for <oauth@ietfa.amsl.com>; Fri, 17 Jul 2020 10:25:58 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450: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 B01AB3A08EB for <oauth@ietf.org>; Fri, 17 Jul 2020 10:25:57 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id k15so6501078lfc.4 for <oauth@ietf.org>; Fri, 17 Jul 2020 10:25:57 -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=w6wL7bNt/8pknM8hwtC5QBpSpCsxQE46tNt+yloj+3g=; b=ovRbpKenJj5vEInIciu0CuJ0wOcSyxZlYBSBN6ZLIfTtNDjLhXT2UNEs48bW3O2kUy gHKAhEXrdi5dTYa2YFuycmZP7WR+rAWQArLLdJVxuuVlEfbUFOt0HzCtSx2HTIiRUCh5 eZO6Kmplg2D7aAsDUmtja7BSucAL5YJeEpaA2DyE4/rcZE3vzOybrRl1PkBVUZhSe+8D nJLhjsnRmSZcG38MwNdypXUrTgLdJs+fScCXv2HPYjRY8pKdbc+QprlYQVGogzGCZsLN nlX8FvNjdbg1oVz/k4JGZh7M278NeaVU5dRbmr+kxZj6gnRjGr4wh0KblszkcVkZ09yR yE5w==
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=w6wL7bNt/8pknM8hwtC5QBpSpCsxQE46tNt+yloj+3g=; b=DGP7qElOgrSXEOwVlgMgPp01e4iuFgL7FMAtzI1l34YQk5vuXvtTz3x2eiQ8wr1uS0 JYyxhBl6Wt/zweA88F90aE+DjBGqmzEaSLldYpMermYzPTsHqtgUDEuf88HQNWxWQIaH +0GdrOxq3TEjYSkZRTsazlcvtgka5O6z0zCp5G1Qrcj6daYdCgjgvgYPAIbnRpA6etys ILxJzSfI0saz45yyTnJ771zHjCsYgnGOcsJy8VHrrBKEUqDrdisf2NPl9a+sJpqaSV6t jSGc9LXp8uQBV+efybQ1zvXXTxSgzYbZipkdw71qqn0tGY9JYgErws/XMqIpI6aFC0vQ aWDw==
X-Gm-Message-State: AOAM533XC970ekDCpR0VntsMz4jKrRyzp1Z3b6vesvQeFP4OJ1d1a4HH 5U3Ruer4wRl3f+arAoFm754JPHpPkPqOjLOPVbXzw04a
X-Google-Smtp-Source: ABdhPJxkiu3zfggnrvq16RRQ1qguiSOur2kNLdTUOX0DKZcVE9WVS71Rlw/9D5dMohAn0vyWi6H5py8JM66dAn2Xoy4=
X-Received: by 2002:a19:64c:: with SMTP id 73mr5213780lfg.0.1595006755568; Fri, 17 Jul 2020 10:25:55 -0700 (PDT)
MIME-Version: 1.0
References: <E9F67961-B83D-40EF-A9CC-F3E4B495379F@mit.edu>
In-Reply-To: <E9F67961-B83D-40EF-A9CC-F3E4B495379F@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 17 Jul 2020 10:25:19 -0700
Message-ID: <CAD9ie-tTTBTGGq_Dw16efNt6OMgDgKnat0_G-AkvDaizgOEjLQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000147fce05aaa67332"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vJNZVIkc5QW6wlknNb5Zl1iyCoY>
Subject: Re: [OAUTH-WG] Namespacing "type" in RAR
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2020 17:26:00 -0000

Hey Justin, glad to see that you have aligned with the latest XAuth draft
on a type property being required.

I like the idea that the value of the type property is fully defined by the
AS, which could delegate it to a common URI for reuse. This gets GNAP out
of specifying access requests, and enables other parties to define access
without any required coordination with IETF or IANA.

A complication in mixing plain strings and URIs is the canonicalization. A
plain string can be a fixed byte representation, but a URI requires
canonicalization for comparison. Mixing the two requires URI detection at
the AS before canonicalization, and an AS MUST do canonicalization of URIs.

The URI is retrievable, it can provide machine and/or human readable
documentation in JSON schema or some such, or any other content type. Once
again, the details are out of scope of GNAP, but we can provide examples to
guide implementers.

Are you still thinking that bare strings are allowed in GNAP, and are
defined by the AS?



On Fri, Jul 17, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:

> The “type” field in the RAR spec serves an important purpose: it defines
> what goes in the rest of the object, including what other fields are
> available and what values are allowed for those fields. It provides an
> API-level definition for requesting access based on multiple dimensions,
> and that’s really powerful and flexible. Each type can use any of the
> general-purpose fields like “actions” and/or add its own fields as
> necessary, and the “type” parameter keeps everything well-defined.
>
> The question, then, is what defines what’s allowed to go into the “type”
> field itself? And what defines how that value maps to the requirements for
> the rest of the object? The draft doesn’t say anything about it at the
> moment, but we should choose the direction we want to go. On the surface,
> there are three main options:
>
> 1) Require all values to be registered.
> 2) Require all values to be collision-resistant (eg, URIs).
> 3) Require all values to be defined by the AS (and/or the RS’s that it
> protects).
>
> Are there any other options?
>
> Here are my thoughts on each approach:
>
> 1) While it usually makes sense to register things for interoperability,
> this is a case where I think that a registry would actually hurt
> interoperability and adoption. Like a “scope” value, the RAR “type” is
> ultimately up to the AS and RS to interpret in their own context. We :want:
> people to define rich objects for their APIs and enable fine-grained access
> for their systems, and if they have to register something every time they
> come up with a new API to protect, it’s going to be an unmaintainable mess.
> I genuinely don’t think this would scale, and that most developers would
> just ignore the registry and do what they want anyway. And since many of
> these systems are inside domains, it’s completely unenforceable in practice.
>
> 2) This seems reasonable, but it’s a bit of a nuisance to require
> everything to be a URI here. It’s long and ugly, and a lot of APIs are
> going to be internal to a given group, deployment, or ecosystem anyway.
> This makes sense when you’ve got something reusable across many
> deployments, like OIDC, but it’s overhead when what you’re doing is tied to
> your environment.
>
> 3) This allows the AS and RS to define the request parameters for their
> APIs just like they do today with scopes. Since it’s always the combination
> of “this type :AT: this AS/RS”, name spacing is less of an issue across
> systems. We haven’t seen huge problems in scope value overlap in the wild,
> though it does occur from time to time it’s more than manageable. A client
> isn’t going to just “speak RAR”, it’s going to be speaking RAR so that it
> can access something in particular.
>
> And all that brings me to my proposal:
>
> 4) Require all values to be defined by the AS, and encourage specification
> developers to use URIs for collision resistance.
>
> So officially in RAR, the AS would decide what “type” means, and nobody
> else. But we can also guide people who are developing general-purpose
> interoperable APIs to use URIs for their RAR “type” definitions. This would
> keep those interoperable APIs from stepping on each other, and from
> stepping on any locally-defined special “type” structure. But at the end of
> the day, the URI carries no more weight than just any other string, and the
> AS decides what it means and how it applies.
>
> My argument is that this seems to have worked very, very well for scopes,
> and the RAR “type” is cut from similar descriptive cloth.
>
> What does the rest of the group think? How should we manage the RAR “type”
> values and what they mean?
>
>  — Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>