Hi Justin, I have couple of questions related to "valid" parameter...
This endpoint can be invoked by the Resource Server in runtime... In that case what is exactly meant by the "resource_id" in request ? IMO a token to be valid depends on set of criteria based on it's type.. For a Bearer token.. 1. Token should not be expired 2. Token should not be revoked. 3. The scope the token issued should match with the scope required for the resource. For a MAC token... 1. Token not expired (mac id) 2. Token should not be revoked 3. The scope the token issued should match with the scope required for the resource. 4. HMAC check should be valid There are similar conditions for SAML bearer too.. Thanks & regards, -Prabath On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer <jric...@mitre.org> wrote: > It validates the token, which would be either the token itself in the > case of Bearer or the token "id" part of something more complex like MAC. > It doesn't directly validate the usage of the token, that's still up to the > PR to do that. > > I nearly added a "token type" field in this draft, but held back because > there are several kinds of "token type" that people talk about in OAuth. > First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within > Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also > got "access" vs. "refresh" and other flavors of token, like the id_token in > OpenID Connect. > > Thing is, the server running the introspection endpoint will probably know > *all* of these. But should it tell the client? If so, which of the three, > and what names should the fields be? > > -- Justin > > > On 02/07/2013 11:26 AM, Prabath Siriwardena wrote: > > Okay.. I was thinking this could be used as a way to validate the token as > well. BTW even in this case shouldn't communicate the type of token to AS? > For example in the case of SAML profile - it could be SAML token.. > > Thanks & regards, > -Prabath > > On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer <jric...@mitre.org> wrote: > >> "valid" might not be the best term, but it's meant to be a field where >> the server says "yes this token is still good" or "no this token isn't good >> anymore". We could instead do this with HTTP codes or something but I went >> with a pure JSON response. >> >> -- Justin >> >> >> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote: >> >> Hi Justin, >> >> I believe this is addressing one of the key missing part in OAuth 2.0... >> >> One question - I guess this was discussed already... >> >> In the spec - in the introspection response it has the attribute >> "valid" - this is basically the validity of the token provided in the >> request. >> >> Validation criteria depends on the token and well as token type ( >> Bearer, MAC..). >> >> In the spec it seems like it's coupled with Bearer token type... But I >> guess, by adding "token_type" to the request we can remove this dependency. >> >> WDYT..? >> >> Thanks & regards, >> -Prabath >> >> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer <jric...@mitre.org> wrote: >> >>> Updated introspection draft based on recent comments. Changes include: >>> >>> - "scope" return parameter now follows RFC6749 format instead of JSON >>> array >>> - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT >>> claims >>> - clarified what happens if the authentication is bad >>> >>> -- Justin >>> >>> >>> -------- Original Message -------- Subject: New Version Notification >>> for draft-richer-oauth-introspection-02.txt Date: Wed, 6 Feb 2013 >>> 11:24:20 -0800 From: <internet-dra...@ietf.org><internet-dra...@ietf.org> >>> To: >>> <jric...@mitre.org> <jric...@mitre.org> >>> >>> A new version of I-D, draft-richer-oauth-introspection-02.txt >>> has been successfully submitted by Justin Richer and posted to the >>> IETF repository. >>> >>> Filename: draft-richer-oauth-introspection >>> Revision: 02 >>> Title: OAuth Token Introspection >>> Creation date: 2013-02-06 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>> Htmlized: >>> http://tools.ietf.org/html/draft-richer-oauth-introspection-02 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02 >>> >>> Abstract: >>> This specification defines a method for a client or protected >>> resource to query an OAuth authorization server to determine meta- >>> information about an OAuth token. >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 <%2B94%2071%20809%206732> >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> >> >> > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
