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

Vladimir Dzhuvinov <vladimir@connect2id.com> Wed, 22 July 2020 20:16 UTC

Return-Path: <vladimir@connect2id.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 0833A3A0858 for <oauth@ietfa.amsl.com>; Wed, 22 Jul 2020 13:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Level:
X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 j_gB0XWuoGNn for <oauth@ietfa.amsl.com>; Wed, 22 Jul 2020 13:16:39 -0700 (PDT)
Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03683A0859 for <oauth@ietf.org>; Wed, 22 Jul 2020 13:16:39 -0700 (PDT)
Received: from [192.168.10.64] ([81.174.4.8]) by :SMTPAUTH: with ESMTPSA id yLALjmSL1kGZCyLAMji3hj; Wed, 22 Jul 2020 13:16:39 -0700
X-CMAE-Analysis: v=2.3 cv=Wo5VzuXv c=1 sm=1 tr=0 a=vVDcMwBpR/yuU2vi46uXpQ==:117 a=vVDcMwBpR/yuU2vi46uXpQ==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=__SxRlIrAAAA:8 a=14VOZv_uNoyZSmLuyPAA:9 a=zvfu1FmlGC681QuV:21 a=GSU1Vi4mV2SUo4eE:21 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
Cc: oauth@ietf.org
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>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <9c6b4565-7042-62cc-6346-4e668bcb0a77@connect2id.com>
Date: Wed, 22 Jul 2020 23:16:37 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <89302FD9-4FBF-4363-8B7E-545AB4A778AD@lodderstedt.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080405030509060804060704"
X-CMAE-Envelope: MS4wfOToJccGNgLNwO4pbHc3H/hRaEOH1hcpJNn8XZdhVMTQ99k9mID9dZngmm9CA0ozUpDR1njlu/S2DFXVhts7FvEnVwpBvObK5hZSnhUW70T2q3PjyMwI T75B/t5oQJI4Y5Qrkjctm4rgO0yZUzxP4zAko5ohE1qvgMb5VKonYgSq
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/d12H-yXFjRO0BeB7Xef-G3K_aGY>
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 20:16:41 -0000

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?

> 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