Re: [OAUTH-WG] Namespacing "type" in RAR
Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 22 July 2020 21:03 UTC
Return-Path: <torsten@lodderstedt.net>
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 BB5293A0998
for <oauth@ietfa.amsl.com>; Wed, 22 Jul 2020 14:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=lodderstedt.net
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 idyaqzxntLXu for <oauth@ietfa.amsl.com>;
Wed, 22 Jul 2020 14:02:59 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
[IPv6:2a00:1450:4864:20::633])
(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 BF2A23A0996
for <oauth@ietf.org>; Wed, 22 Jul 2020 14:02:58 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id w9so3784409ejc.8
for <oauth@ietf.org>; Wed, 22 Jul 2020 14:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lodderstedt.net; s=google;
h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
:references; bh=jLOvDnFUK/UDw5yTgm+11Hur42Nl4DM9UfMsxvtU9Tg=;
b=3dvehO9FYZY+IC0xFzFlPgyk1gRLRuYM9ImWcWqvmqRK4I/TcUfMp8WU4PZ7Ys+FIy
wXaauIT50Z1l7n6DM+XyKL7FcY4DHP+0/4dWMtJdPwxfYvgV4vkDk3r3WwsVdIztwIqu
8Al1ZojUv4NucVebR5KpDxGT1G2pNmJ2/tkeLFGtnecC90XgOjRvJg2GfmX/DDj1qnIz
H2pXpXfCwDykv9twJWPRzGA8MNbIxVqUdbkDJqVZgZK6f5MMT06gOQPJG/fAmj3vjRG2
wFp45Zw6R6qMa4l0ei4SYgmi6KVmSi6KAFU7e1+s8PcXvnomvy97VK0KEolWv/MkQhaP
fPmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:message-id:mime-version:subject:date
:in-reply-to:cc:to:references;
bh=jLOvDnFUK/UDw5yTgm+11Hur42Nl4DM9UfMsxvtU9Tg=;
b=I9Q4jsGJqEFmDNs52qNvM4OSNh6oED/0EQhmXmkv3Nr9odhWB+Ruot02hgqhQU/m7V
x4wo/mxaRzXjED5npv9ru97+OgHD0qReGOpR+tP8Gy1G3CDuctM5Jm5umV/jwcwUvS2r
TDt+p94EALKh+74pDGJTkB8hlGJpxBkwvg1dTugyYfv+l5tTlZErhi7dSH9pFqYbVy8C
3KL9UxUz7W0a72YYRVVXbZ6aCfP430Rx8KXyOoA1kipPsAMDaS2BDofqVvWGOToguvdG
jko6+RcU7KD+2jDaQbWXsXxYIkZ99yn0Lc0VUKWoFvGmsFUxUPLiKXdiiiNHvLxz/W0U
0cog==
X-Gm-Message-State: AOAM531u7fUljMT308WwshkFa/HQnXuq98KLER2Xnu2WIO6N6xBBkRjV
pHUb4v09fdEcEdrAfhMGLdk8VqHp4NU=
X-Google-Smtp-Source: ABdhPJzVnOUxe8ZJILs0tOA90IFySXinvQemE1XHkY/tD3w2fBX0gEGkFa9yudIXuTDh7dGSYUn6+w==
X-Received: by 2002:a17:906:35cd:: with SMTP id
p13mr1405550ejb.172.1595451777099;
Wed, 22 Jul 2020 14:02:57 -0700 (PDT)
Received: from p200300eb8f0138564448aa37b13c8450.dip0.t-ipconnect.de
(p200300eb8f0138564448aa37b13c8450.dip0.t-ipconnect.de.
[2003:eb:8f01:3856:4448:aa37:b13c:8450])
by smtp.gmail.com with ESMTPSA id m14sm501188ejx.80.2020.07.22.14.02.55
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Wed, 22 Jul 2020 14:02:56 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <0F86826A-14B0-4047-80C2-4D503C97763E@lodderstedt.net>
Content-Type: multipart/signed;
boundary="Apple-Mail=_129B1EF8-D935-4E0D-9797-ED501BF9754F";
protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 22 Jul 2020 23:02:54 +0200
In-Reply-To: <9c6b4565-7042-62cc-6346-4e668bcb0a77@connect2id.com>
Cc: oauth@ietf.org
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
References: <E9F67961-B83D-40EF-A9CC-F3E4B495379F@mit.edu>
<4ea6f9af-d67f-97df-6bae-752cf34f920c@connect2id.com>
<B5B80874-7A8F-4B9B-AA97-0516661F4E9D@mit.edu>
<c84ca5ce-5fa0-dc8e-afaa-88f48dc6eaa8@connect2id.com>
<5EFFFABC-2A9B-4353-A826-2D33D4E82600@mit.edu>
<9ee8ed17-141c-1aeb-901a-4d91d6aa90b0@connect2id.com>
<89302FD9-4FBF-4363-8B7E-545AB4A778AD@lodderstedt.net>
<9c6b4565-7042-62cc-6346-4e668bcb0a77@connect2id.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ycaIzxZQFqYQS_AySrjnJO40oMc>
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: Wed, 22 Jul 2020 21:03:01 -0000
> On 22. Jul 2020, at 22:16, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote: > > > On 21/07/2020 18:43, Torsten Lodderstedt wrote: >> >>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote: >>> >>> >>> >>> On 21/07/2020 17:47, Justin Richer wrote: >>>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote: >>>>> >>>>> On 18/07/2020 17:12, Justin Richer wrote: >>>>>> I think publishing supported “type” parameters isn’t a bad idea, and it aligns with publishing supported scopes and claims in discovery. >>>>> If you are a developer, would you like to be able to find out if the authorization_details for a given "type" has a JSON schema and what it looks like? >>>>> >>>>> >>>>> >>>> I think that would be a nice thing for an AS/API to offer, but I don’t think it should be expected or required here. That might be a good note in the guidance, say that if you use a URI for your “type” field then it would be nice if it resolved to something either human or machine readable. What I don’t want is for us to require every AS to have to resolve these URIs in order to process and understand them. That’s why I’m taking the position of it being a string, and the URI can provide disambiguation in the way you’re talking about below. >>> We've been thinking about giving developers the possibility to discover the authorization_details JSON schema (if one is supplied) for a given type via a separate AS metadata parameter. Not by making the type a dereferceable URL, which will overload things too much. >>> >>> authorization_details_json_schemas : { >>> "<type-a>" : "<type-a-json-schema-url>", >>> "<type-b>" : "<type-b-json-schema-url>", >>> ... >>> >>> } >>> The rationale -- to minimise the number of potential support calls for providers arising from "Oh dear, why do I get this invalid_request now..." with complex RAR JSON objects. >> We could borrow the "$schema” element. > > Could you elaborate? I mean we could use this element in addition to the “type” element to specify the corresponding schema in each authorization details object. > >> However, I’m on the fence regarding introducing a separate parameter for the schema simply because it also introduce a new error cause if type and schema are inconsistent. > > Another idea was to still let the AS be configured with optional JSON > schemas for each type, and if the schema check of the > authorization_details fails, to include a meaningful message in the > invalid_request error_description and the schema URL in the error_uri. > > The downside of that is the schema cannot be discovered or retrieved > upfront. > > We really want to make it easy for developers to debug their requests > when facing complex RARs, on their own, without having to rely on a > support desk. > > IMO the std invalid_request is ok for communicating the condition of an > authorization_details object failing the schema check (if the additional > error code was your concern). > > Vladimir > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Namespacing "type" in RAR Vladimir Dzhuvinov
- [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Dick Hardt
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Dick Hardt
- Re: [OAUTH-WG] Namespacing "type" in RAR Vladimir Dzhuvinov
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Dick Hardt
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Vladimir Dzhuvinov
- Re: [OAUTH-WG] Namespacing "type" in RAR Torsten Lodderstedt
- Re: [OAUTH-WG] Namespacing "type" in RAR Dick Hardt
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Dick Hardt
- Re: [OAUTH-WG] Namespacing "type" in RAR Dick Hardt
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Dick Hardt
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Joseph Heenan
- Re: [OAUTH-WG] Namespacing "type" in RAR Vladimir Dzhuvinov
- Re: [OAUTH-WG] Namespacing "type" in RAR Torsten Lodderstedt
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Brian Campbell
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer
- Re: [OAUTH-WG] Namespacing "type" in RAR Torsten Lodderstedt
- Re: [OAUTH-WG] Namespacing "type" in RAR Justin Richer