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