The more I’ve been thinking about it, the more I like the idea of using “$schema” for that purpose. It’s already got a well-defined definition in the JSON Schema world that would be familiar to people doing that, and there’s no need to overload the “type” field for that purpose. You would be able to do the same thing with the “@context” field from JSONLD, which has similar semantics. If we tried to put those both into the “type” field, and AS would have a hard time supporting both types of APIs, and so our goal of allowing easy differentiation at the AS isn’t really met.
A quick straw man idea: We :could: define a value for “type” that is “https://schema.org/ <https://schema.org/>“ and have it define the “$schema” field and how to process the rest of the object using JSON Schema. Similar idea for something JSONLD based, it uses “https://json-ld.org <https://json-ld.org/>” and defines a “@context” field that says how to process the rest of the request object using JSON-LD. And in all of these cases, the “type” field is always checked by the AS by doing a simple string comparison. The URI here is just to keep the two public spaces from stepping on each other in their definitions. As for Joseph’s comment about unicode: I think we can recommend that people use ASCII because of the usability concerns, and use string comparison to check and compare. — Justin > On Jul 22, 2020, at 5:02 PM, Torsten Lodderstedt > <torsten=40lodderstedt....@dmarc.ietf.org> wrote: > > > >> On 22. Jul 2020, at 22:16, Vladimir Dzhuvinov <vladi...@connect2id.com> >> wrote: >> >> >> On 21/07/2020 18:43, Torsten Lodderstedt wrote: >>> >>>> 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. >> >> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
