[GNAP] Accounting for Resource Owner in RS::AS interactions

Josh Mandel <jmandel@gmail.com> Mon, 27 September 2021 17:56 UTC

Return-Path: <jmandel@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1602C3A1010 for <txauth@ietfa.amsl.com>; Mon, 27 Sep 2021 10:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FpWc_XQ4F4Mz for <txauth@ietfa.amsl.com>; Mon, 27 Sep 2021 10:56:36 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 6C67B3A100F for <txauth@ietf.org>; Mon, 27 Sep 2021 10:56:36 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id i84so25835386ybc.12 for <txauth@ietf.org>; Mon, 27 Sep 2021 10:56:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=GFY/pfgbKvdZiMxXcOoYhn9S+DihUicMI+e+7/FIrWY=; b=hSkLyfhgUNvpO0Q83WOlIGsp+suwlo37GcQirSfo5CBBXDSNeuVPM6B9JhiBlI6cPT pjxMekz4qoDJs6FGyhOelKc8Zsoqk/VLj046dcTKhvavacY11wtmlI9NZlm2qxfFR4RC GVHCRIuM2mBYtiZcDpeggrBF70fanNEUtdQrxNBt2tT2JhgXdjhoSduUdvkhe8LDUm0z H1zAjvkr7YmPdBXA/qb3Cja9RHxfbC4ELw/QJOJ74Zef4Gkj9kUX9n2MZcfxbIejdE1p 7evH/d4Od6g/WiVmxwQH1Wby1Rd1Eo5ePAo1F+rNhfS82/QrHadEQXUX5pIcX75J97Wl 3x1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GFY/pfgbKvdZiMxXcOoYhn9S+DihUicMI+e+7/FIrWY=; b=WebYBiPavQOY9Mj+aUkVaBHP3bw0taSu9a2W7LoF6qZtEKi4YmuZvN8rLt3sw22zgE SJc+OS2MXVNGk0GsvYQ6kMRm+9fmIVSLVs5rjFmOSl88VnSlyT12ekEQOYmIHwu7ruiJ rYcc0wMMRct0k6VGwVMtmNUWVMsl48x+EbAh1ZMVC5ZtRU0/dLzYgL7MS3D0Irskv/ne BVVcYP4qbjX9wK2nMGlBIydrx75E0gLSKRKbtGNTA+GncWnIWw+xpnRTiKeU4W6I4CcB I1dxh9TmBvuOV8/prqFS/aly6VDzoS6BQxuiOKVgjG+QSk4B9269yPosUGMpH16sFULy PpDQ==
X-Gm-Message-State: AOAM531z3XQ/zInY75ryPnrKlo++t0t+i3e4IwZpGTVmi3ppgLuc25Za SeQlRK0oGfH1aMABhWBaoqVP5879SInF5ASSkKXUu7hxFU4=
X-Google-Smtp-Source: ABdhPJxmMEBsa3IcSLapOnMtkjcFTY3rl5G8qbig5xIMwFH50UigyngZU89HsfFlI2fPpCL1uRpJDZX136ZapQ1/CIQ=
X-Received: by 2002:a25:1246:: with SMTP id 67mr1178612ybs.461.1632765394947; Mon, 27 Sep 2021 10:56:34 -0700 (PDT)
MIME-Version: 1.0
From: Josh Mandel <jmandel@gmail.com>
Date: Mon, 27 Sep 2021 12:56:18 -0500
Message-ID: <CANSMLKHx4xKrR+c-KzdpxF0==c_=wqPexQJTVNTEXVmU5Usm9g@mail.gmail.com>
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005e1c1e05ccfdd1a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/yyEorsXEy7ZR8v2lWx79kjIQ_u0>
Subject: [GNAP] Accounting for Resource Owner in RS::AS interactions
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 27 Sep 2021 17:56:40 -0000

Hi All,

I'm interested in exploring how GNAP can/does/might account for the
Resource Owner associated with specific protected resources, in scenarios
where a single AS is trusted by multiple independent RS's (specifically in
scenarios where these RS's don't know or trust one another). Justin
suggestd I might reach out here.

My sense is that there are security considerations related to these
questions, and perhaps some best practices or even areas where the core
spec's data models could be enhanced to support these scenarios. I'm not
proposing anything in particular at this stage; just trying to get the lay
of the land.

See assumptions and scenarios below.



*Assumptions. *I'll focus on a very simple API from the RS perspective: a
standardized file access API where resource servers would like to make
access control decisions based on access tokens whose RARs look something

  "type": "file-access",
  "actions": ["read"],
  "location": ["{{URL of one protected file}}"]


*Scenario 1. *Consider the case where a single RS manages files owned by
multiple end users. The RS uses a single AS for all files (but the AS also
serves other untrusted RS's). Each RO is allowed to set authorization
policies for their own files. In this scenario, how does the AS learn which
RO is responsible for setting policies for each file, so it can present
Alice with a list of current policies, allow her to review/tweak access,
etc? (If an AS is confused on this point, there's a risk that Bob can set
policies for Alice's files.) It's possible that the Resource Registration
API could be extended to model this kind of ownership, if both servers have
some interoperable way to communicate user identities. I'm not sure if
there are existing patterns to recommend here? It's also very important for
the RS to know, whenever it receives an access token, that the RS is an
intended audience for that token. The RAR "locations" aren't enough to
accomplish this, unless the AS has a reliable scheme in place to prevent
one RS from crafting RARs that refer to resource locations within another
RS.  And as the spec says, the AS introspection endpoint needs to ensure
that access tokens are "appropriate for presentation at the identified RS".
But that's especially challenging when a single access token can include
multiple RARs, potentially intended for different RS's (which appears to be
allowed by the base spec). And for structured token formats where
introspection isn't required, the same questions hold; is there existing
work on this?

*Scenario 2. *Now consider the case where 10 organizations each manage a
File Sharing RS. Each RS hosts files for multiple ROs, and the ROs get to
choose which AS should be trusted for their own files. In this context, I
suppose the workflow that introduces the RS to the AS can be mediated by
the RO, so that the RO is logged into both systems when making the
introduction, and the RS can essentially register a new client instance
with the AS for each RO who decides to establish a connection. This pattern
has the advantage that there's no confusion about *who* controls a given
resource -- but perhaps there are other, better ways to accomplish this.