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

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 21 July 2020 15:43 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 985313A0BBA for <oauth@ietfa.amsl.com>; Tue, 21 Jul 2020 08:43:15 -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 DxkvBUtQXfyw for <oauth@ietfa.amsl.com>; Tue, 21 Jul 2020 08:43:13 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 E946E3A0B9C for <oauth@ietf.org>; Tue, 21 Jul 2020 08:43:10 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id lx13so22130030ejb.4 for <oauth@ietf.org>; Tue, 21 Jul 2020 08:43:10 -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=fBx8fxn46I9EG93ZB/Tfc1OjSx2oliF6QLzX9spHbbU=; b=Y8pa50FBt1Cq+/9LAUDrHG65jzyD4SMAohDPwhSg9AcUvZQ0IuOWlilDbqJ5c5XrEF kGz+nuEp2XcBtr/uAl/v5EaEDEgHJHNB6y6RWaLk4NX7qZzuZZJE54d3EbkAL65DSdtK I2RE3m0adBboldiIuattVJvB/H3MxzMyasrjF+w0XAs1DN2GQmRR3q+qjfUMbBYcKT0H 4gZaq/Ahz3fPq6JJi16o1Pjg0iHaIQMtAzpyCvDmYW/SkWVp8FYQ4KxxcE+X8D1RwQIO DiiKV9s8sMm3mA50/S0/AsoqABhuYx1tvvFliVvyoxviFy98RhXFkSctaKYbRYKVVYJq JMYw==
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=fBx8fxn46I9EG93ZB/Tfc1OjSx2oliF6QLzX9spHbbU=; b=oc2xZ+GN0i7/RZ/wpWLLH/zxfCYpidVOpShgQnkyV/hERt3pIdPdg10XOymFcbUnFY 8mMjvpPIK+gpTyo4jYabLIXXhYYX1Er6q84Uh+0mfhE2LAHz7H78JnKD2dQ2ArTkE3l0 OJxmPAEGJMgTw5CIObrVAP68QG4U/Hxqi7x9lTEdw5OvARET0pmNu5yOiAx0wVRYBkgz ydMPT+uSm9OO+xKfulXIpzmcJqrC5rpbcPT53Fpr8WAVuIbG8HuGmlZQy/SnHEBGQE6U 7EidvPh+3QKr/auyKuhDKQ7vGcW/i6LDK2zAxjb9GanKsHPzzeCJrnQ/VX5YPRc21jvt gsyw==
X-Gm-Message-State: AOAM530CB9oGoCj26bCiobP+tgjmSULHfdqfpEbdA1W/3JN1X/HEMwj6 TNesLFFCbsKJktLm1P4snTfemw==
X-Google-Smtp-Source: ABdhPJyICq6HoIKHtRPK3m6lFh8/6CIYlBzHabfnJfehuIbSRF4dGpBeQVyyfwH9oTYaMt/pQoO0rQ==
X-Received: by 2002:a17:906:a892:: with SMTP id ha18mr26548511ejb.462.1595346189104; Tue, 21 Jul 2020 08:43:09 -0700 (PDT)
Received: from p200300eb8f0138082464f306cb2f9290.dip0.t-ipconnect.de (p200300eb8f0138082464f306cb2f9290.dip0.t-ipconnect.de. [2003:eb:8f01:3808:2464:f306:cb2f:9290]) by smtp.gmail.com with ESMTPSA id z101sm17821190ede.6.2020.07.21.08.43.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2020 08:43:07 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <89302FD9-4FBF-4363-8B7E-545AB4A778AD@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_A4F37BB5-FE3A-4584-BAE0-D5DA206A5F73"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 21 Jul 2020 17:43:06 +0200
In-Reply-To: <9ee8ed17-141c-1aeb-901a-4d91d6aa90b0@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>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Rf0m01r1omRRsaPeYss1sbfB6i0>
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: Tue, 21 Jul 2020 15:43:16 -0000


> 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. 

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. 

best regards,
Torsten. 

> 
> 
> 
> Vladimir
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth