There’s a whole host of client information that “might” be helpful to an RS, but I don’t think it would be helpful for us to try to determine all of that information since, as far as I know, there is no implementation today that is passing that kind of information over. Especially consider that whether the client is public or not has no bearing over how the token is presented to the RS.
If in the future someone wants to standardize that kind of information as an extension to introspection, the data model used in Dynamic Registration could be referenced for this purpose. But something like that very much belongs in an extension after there are at least a couple implementations of it. — Justin > On Dec 19, 2014, at 6:13 PM, Sergey Beryozkin <[email protected]> wrote: > > Hi Justin > > returning a client public/confidential status may be useful in case RS > chooses to allow for a more restricted access to public clients in cases > where both public & private clients are accepted > > Thanks, Sergey > On 09/12/14 15:59, Sergey Beryozkin wrote: >> Hi Justin >> >> IMHO the section 2.1 [1] requires more work. >> >> First, "resource_id". Having such a parameter does not add anything to >> the interoperability side of the spec. It is a "server specific >> string..." which may be anything and as such a 3rd party AS is unlikely >> to do any work around this parameter unless both RS and AS are from the >> same provider. >> IMHO it either has to be dropped, the text "The endpoint MAY allow other >> parameters to provide further context to the query" covers whatever else >> that server may want to add or attach some more specific meaning to it. >> Besides that, the MUST authentication requirement covers properly a >> possible RS identification requirement. >> I'd rather have a "resource_id" representing an RS base address or >> better, a current request URI, which in combination with an optional >> client_ip can help AS to make a more specific introspection action. >> >> I also suggested to promote a parameter like "client_ip". Just referring >> to a possibility of RS reporting a client IP adress does not help >> improving the interoperability either with respect to RS and AS offered >> by different providers working with a client IP property >> >> Thanks, Sergey >> >> >> >> [1] >> http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1 >> >> >> >> On 07/12/14 03:38, Justin Richer wrote: >>> … and I just noticed hanging text at the top of section 2.2 due to the >>> JWT claims edit. My working copy has removed the extraneous text >>> “Several of these”. >>> >>> Also, as always, latest XML is up on GitHub: >>> >>> https://github.com/jricher/oauth-spec >>> >>> — Justin >>> On Dec 6, 2014, at 10:34 PM, Justin Richer <[email protected]> wrote: >>> >>>> Small update to introspection, now the returned values reference the >>>> JWT claims specifically (as requested). Also updated the HTTP and >>>> HTML references. >>>> >>>> No normative changes. >>>> >>>> — Justin >>>> >>>> On Dec 6, 2014, at 10:32 PM, [email protected] wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Web Authorization Protocol Working >>>>> Group of the IETF. >>>>> >>>>> Title : OAuth 2.0 Token Introspection >>>>> Author : Justin Richer >>>>> Filename : draft-ietf-oauth-introspection-03.txt >>>>> Pages : 12 >>>>> Date : 2014-12-06 >>>>> >>>>> Abstract: >>>>> This specification defines a method for a protected resource to query >>>>> an OAuth 2.0 authorization server to determine the active state of an >>>>> OAuth 2.0 token and to determine meta-information about this token. >>>>> OAuth 2.0 deployments can use this method to convey information about >>>>> the authorization context of the token from the authorization server >>>>> to the protected resource. >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-oauth-introspection-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-03 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
