> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov <vladi...@connect2id.com> wrote:
>
>
>
> On 21/07/2020 17:47, Justin Richer wrote:
>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov <vladi...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
