Re: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access

Warren Parad <wparad@rhosys.ch> Sat, 23 March 2024 10:09 UTC

Return-Path: <wparad@rhosys.ch>
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 25BB6C14CEF9 for <oauth@ietfa.amsl.com>; Sat, 23 Mar 2024 03:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhzual9hRb0p for <oauth@ietfa.amsl.com>; Sat, 23 Mar 2024 03:09:48 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5F4C14CEFF for <OAuth@ietf.org>; Sat, 23 Mar 2024 03:09:48 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a469dffbdfeso111514466b.0 for <OAuth@ietf.org>; Sat, 23 Mar 2024 03:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google2024; t=1711188586; x=1711793386; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RIjsodIzRYd6FJax4wT57t/XRjIwL1JTfOqlGEOIeOw=; b=j1O/gS1mDMHsepAhUhPI/R+ZT25yJFyu9hilqyoeYldXNhMm1UbHgpwIG4xqofDk5J 9BABJD/qy6xTdcz2DAjLHx+0pfy/kHKYd1gSiL4MkDkwbfeBkX4IO7w4Oc2uU9LGAxtA kMbNUsFZvrTFk8bOuSwbuiwJFJo+ESFdNa6CJ7nubULZdx3dGkSP1AfX/nnO6KKEegSn YXQAIz9+ohMysgi9zs1RXnDeVYtXI+EpfapsRT+M9rrgVwzrCj6lUXz6ou+wdajp8n8w yP78msr6oVOJtpM5Ycz7gKv81pT615ga6U6YGTYGPNlt6IpRsx5v5xR5Pz8PDKlH+VD0 8Iyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711188586; x=1711793386; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RIjsodIzRYd6FJax4wT57t/XRjIwL1JTfOqlGEOIeOw=; b=QS+9rxE8AYg6JS5UuhfRPRmw7X3AoleS0a3i/405/VX/eB4rkFO4RwjNfX0mUzSCgP mu/h7Tg45Ai6hUdd+vtLP2jps3yJfLmdIGqBjkLZh0qj325L4GGcfBNWJ4Wn7djkE9t2 zwg7lSGvwR8j9h3rP2etRNN0W7q5Hxqta1MNs9hHYILNsu9pBlhlA/1J/UIojj7zNXIx z2tSYDHeBHWb0tk/F3R0AJHxEILu/0nm0h8gLcRSUpkoAunu0kwZx2aeFoKpvOlIjCZR tIr980SVkh73h4m5N3ef8HiV+jIqhr2oGj+4ymUHmIT2NycEpeUxxnUfRZkDE1ZbxMsh vjnQ==
X-Forwarded-Encrypted: i=1; AJvYcCWJb99pxfuqZekfWXK0ljfxQGFNLupu2eeYiB7BwCv4IgJ6fzQcCBQS0NqznKqynFRLpN86Be+euJF+wXshOw==
X-Gm-Message-State: AOJu0YwICYyIhADSCTJrzC1DNnWcuzJRo93KgMqxLLZ6hm5uZtifGtwv 5xgrd4Bo6weXPRNHl5VPFdtAHzyzJ2tfbbiLCQYBeAjBQCS7R8ptPI8ZkZixIGqjUVuQZZy9Lp7 CxTOymyKO6sv8ZP2tSPvdCams7iPI7lIgDJc9c0BPb9PfAsc21GmA
X-Google-Smtp-Source: AGHT+IEKx523rQT1vdGiFyco525s1j0Rhs15KdgCa5SkkcwCC28jrk5Q/aIrQHvBXKGHPXf9hIVjPRzSrkGTjgV6fEE=
X-Received: by 2002:a17:907:7212:b0:a45:cdd7:c481 with SMTP id dr18-20020a170907721200b00a45cdd7c481mr1733763ejc.1.1711188585617; Sat, 23 Mar 2024 03:09:45 -0700 (PDT)
MIME-Version: 1.0
References: <eb5d039.2726.18e5985d157.Coremail.jiangcheng612@163.com> <LV8PR01MB8677E37852D44BF495B13FABBD302@LV8PR01MB8677.prod.exchangelabs.com>
In-Reply-To: <LV8PR01MB8677E37852D44BF495B13FABBD302@LV8PR01MB8677.prod.exchangelabs.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Sat, 23 Mar 2024 11:09:34 +0100
Message-ID: <CAJot-L3k2CzxUpQwvFuiHmJmCmon=UZ-vvc+CqKX01cmXL+TqA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: jiangcheng <jiangcheng612@163.com>, "OAuth@ietf.org" <OAuth@ietf.org>, zhangjl382 <zhangjl382@chinaunicom.cn>, jill32 <jill32@chinaunicom.cn>
Content-Type: multipart/alternative; boundary="000000000000ca3a2a06145123be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/uO7NKvoOZ6M7YRTzX3Y3Z3bI6Vo>
Subject: Re: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 23 Mar 2024 10:09:52 -0000

Some thoughts in no particular order, but mostly I'm with Justin:

   1. The exact data properties of the json probably don't belong in this
   RFC, but rather can be used as an example in the RFC rather than
   anything normative, as the structure defined herein is not sufficient in
   many cases. Depending exactly on how (#2) is done, needs to be more
   extensible or potentially completely ignored since any JSON or even string
   could be used to achieve #2.
   2. The mechanism of how to use the json to encrypt and decrypt the
   message feels like the only relevant/interesting detail here and it is the
   main detail left out.

I'd recommend cutting the context related to the structure of the request
(#1) and focus on how it will be used to encrypt/decrypt payloads (#2).

- Warren


On Sat, Mar 23, 2024 at 10:38 AM Justin Richer <jricher@mit.edu> wrote:

> Thank you for presenting your proposal to the group in Brisbane.
>
> Reading through the draft, it seemed that there are really two topics in
> here, and I'm wondering how they could be split:
>
> 1, a data structure for complex access rights
>
> 2, a cryptographic mechanism for selectively encrypting some of those
> rights to protect them from unintentional audiences.
>
> The data structure used to convey the access rights seems very similar to
> the object structure defined by RAR, RFC9396:
> https://www.rfc-editor.org/rfc/RFC9396
>
> I was unable to find something in this data structure that is required to
> provide the cryptographic hiding functionality, have I missed something? Or
> would it be possible to apply this to RAR objects?
>
> Does the key distribution happen or of band of the protocol? In the oauth
> world, would these keys become part of the RS configuration?
>
> Thank you,
>
> - Justin
> ------------------------------
> *From:* OAuth <oauth-bounces@ietf.org> on behalf of jiangcheng <
> jiangcheng612@163.com>
> *Sent:* Tuesday, March 19, 2024 9:42 PM
> *To:* OAuth@ietf.org <OAuth@ietf.org>
> *Cc:* zhangjl382 <zhangjl382@chinaunicom.cn>; jill32 <
> jill32@chinaunicom.cn>
> *Subject:* [OAUTH-WG] draft-zhang-jose-json-fine-grained-access
>
>
> Dear oauth,
>
>
>
>       We have a draft and we are looking forward to soliciting comments on
> it.
>
>       https://datatracker.ietf.org/doc/draft-zhang-jose-json-fine-grained-access/
>
>
> Best regards
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>