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

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 21 July 2020 15:40 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 7B64D3A0B2F for <oauth@ietfa.amsl.com>; Tue, 21 Jul 2020 08:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.877
X-Spam-Level:
X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 mROfQQXHMCIo for <oauth@ietfa.amsl.com>; Tue, 21 Jul 2020 08:40:13 -0700 (PDT)
Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (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 3799A3A0B19 for <oauth@ietf.org>; Tue, 21 Jul 2020 08:40:13 -0700 (PDT)
Received: from [192.168.10.64] ([81.174.4.8]) by :SMTPAUTH: with ESMTPSA id xuNEjsAxbWl2lxuNHjyikc; Tue, 21 Jul 2020 08:40:12 -0700
X-CMAE-Analysis: v=2.3 cv=P/lEeRIu c=1 sm=1 tr=0 a=vVDcMwBpR/yuU2vi46uXpQ==:117 a=vVDcMwBpR/yuU2vi46uXpQ==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=Z4SGUHCehHn_8yKBUucA:9 a=9e9U9rrZdsrFzqbZ:21 a=Vljy4I8DUTwr3xYs:21 a=QEXdDO2ut3YA:10 a=ewdk0vvHfyRhXx0wSCYA:9 a=oN_F3Yc7nvIw89DR:21 a=svVAWdQa0FCibpvb:21 a=rlfelC72giO_37Ou:21 a=_W_S_7VecoQA: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>
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: <9ee8ed17-141c-1aeb-901a-4d91d6aa90b0@connect2id.com>
Date: Tue, 21 Jul 2020 18:40:07 +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: <5EFFFABC-2A9B-4353-A826-2D33D4E82600@mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050201070107080109050901"
X-CMAE-Envelope: MS4wfCHgRsYN35jv8JAUlIcfipZRxNl8UR+72qyY1eOsygq9ovdi/7/fI2DMXGgF43FbUb9A0IvfIHyUVJ+vp9KuXbr4aFKWCsb3OCgebn7pcpcXRdKI7Zlo XWGVdLqJ48tucrfzU7oX9iCHzZz/HkRbdUfTy9luAMKNWvSPhS2+5o/m
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/v_smUTEz2wOS8XuqrPVXcEJ31mg>
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:40:15 -0000

On 21/07/2020 17:47, Justin Richer wrote:
>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov
>> <vladimir@connect2id.com <mailto: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.


Vladimir