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

[Torsten Lodderstedt <[e-mail]>]

> On 22. Jul 2020, at 22:16, Vladimir Dzhuvinov <[e-mail]> wrote:
> 
> 
> On 21/07/2020 18:43, Torsten Lodderstedt wrote:
>> 
>>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> On 21/07/2020 17:47, Justin Richer wrote:
>>>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth