Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

Justin Richer <jricher@mitre.org> Thu, 14 February 2013 16:16 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E8321F8861 for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 08:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level:
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbN4p385sBYC for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 08:16:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 10F9121F886A for <oauth@ietf.org>; Thu, 14 Feb 2013 08:16:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8DB8F1F2CEE; Thu, 14 Feb 2013 11:16:49 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6FCBD1F07F7; Thu, 14 Feb 2013 11:16:49 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 11:16:48 -0500
Message-ID: <511D0DC3.7000607@mitre.org>
Date: Thu, 14 Feb 2013 11:16:03 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena <prabath@wso2.com>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5113DDB2.7060805@mitre.org> <CAJV9qO_gM1oera9ae9sqh9n17e-ZLKuC2pmsZwhq-RmFcMyqHA@mail.gmail.com> <51196777.6000502@mitre.org> <CAJV9qO-5bWZbNUfCmaqYBQoy-qwNaSZFOsO9GL3CrbSejwVTzw@mail.gmail.com> <F6595A40-6B4E-4718-ABB5-694CA975C4DB@maymount.com> <511A5062.5010108@mitre.org> <CAJV9qO_Mr87NX=KZRqCsWasQ1FuvDNBw14eS-TcPf_KRJztQFg@mail.gmail.com> <CAJV9qO-71-sM6kXOB6Fb_bvVkDBQ5JBbs8E5X=f-K=iEmGezRA@mail.gmail.com> <511CEEAA.3030801@mitre.org> <CAJV9qO-JSXgSTkw2_pdH0D-o-xDWGDqxx=PAWYtnTj4hOQXW4Q@mail.gmail.com> <CAJV9qO9=+kiO-s7vH_ewr7XjfVdDU24F0kuif504bP53dBr1TA@mail.gmail.com> <511CF3EF.8040008@mitre.org> <CAJV9qO8yKkrsV7d9JtDmbLY-fb5phh=ssKbEUuutkY53PgY8Vg@mail.gmail.com> <511CF4AB.5010700@mitre.org> <CAJV9qO9VmjSQnWKU3kF11x35ut=AsvQ8bjuz_CKpyCScGRiA2Q@mail.gmail.com> <511CF8C5.70301@mitre.org> <CAJV9qO_-kFsWxoJwTP_RWFrb6+3frg-36JocQoo8SrpyNBMSoA@mail.gmail.com>
In-Reply-To: <CAJV9qO_-kFsWxoJwTP_RWFrb6+3frg-36JocQoo8SrpyNBMSoA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000109060609020608000502"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 16:16:53 -0000

That much I can at least do. I'd be happy with another term if there was 
a good one we could drop in its place without changing the intended 
semantics.

  -- Justin

On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:
> Not quite convinced :-) Valid has a meaning attached to that..
>
> In case we are going ahead with this please define it clearly in the 
> draft - with the one you shared in this thread.
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer <jricher@mitre.org 
> <mailto:jricher@mitre.org>> wrote:
>
>
>     On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:
>>     The definition of valid is bit ambiguous in the draft...
>>
>>     Okay.. If that is the definition... and if we beak that in to
>>     parts...
>>
>>     "it hasn't expired" : In the response it self we have parameter
>>     for issued_at and and expires_at - so whether the token is not
>>     expired or not can even be derived at the requestor's end.
>
>     If the token isn't good anymore, it doesn't matter when it was
>     issued or when it was expired, just that it has.
>
>
>>
>>     "token was issued from here" : For this IMO we need to send an
>>     error code. Requestor has picked the wrong AS.
>     We don't know if it came from another AS or if someone's just
>     making things up. Either way it's not a good token.
>
>
>>
>>     The remaining is  "revoked".. That is why I proposed earlier - we
>>     better have an attribute "revoked" - instead of "valid" in the
>>     response..
>
>     The end result of all three is the same: either the token is good,
>     or it isn't. I think it's much simpler and more useful to leave it
>     at that.
>
>      -- Justin
>
>
>>
>>     WDYT...?
>>
>>     Thanks & regards,
>>     -Prabath
>>
>>
>>     On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer <jricher@mitre.org
>>     <mailto:jricher@mitre.org>> wrote:
>>
>>         Because it will be the one that issued the token in the first
>>         place.
>>
>>         Validity means "token was issued from here, it hasn't been
>>         revoked, it hasn't expired".
>>
>>          -- Justin
>>
>>
>>         On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:
>>>         Okay. With out knowing the type of the token how can the AS
>>>         validate the token ? What is meant by the validity there?
>>>
>>>         Thanks & regards,
>>>         -Prabath
>>>
>>>         On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer
>>>         <jricher@mitre.org <mailto:jricher@mitre.org>> wrote:
>>>
>>>             OK, I don't see the utility in that at all. What would
>>>             it accomplish?
>>>
>>>              -- Justin
>>>
>>>
>>>             On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>>>>             To make it clear - my suggestion is to add
>>>>             token_type_hint to the introspection request. It can be
>>>>             from client to AS or from RS to AS.
>>>>
>>>>             Then AS can decide whether the provided token is valid
>>>>             or not and include "valid" attribute in the
>>>>             introspection response.
>>>>
>>>>             Thanks & regards,
>>>>             -Prabath
>>>>
>>>>             On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena
>>>>             <prabath@wso2.com <mailto:prabath@wso2.com>> wrote:
>>>>
>>>>                 Both the client and the resource owner should be
>>>>                 aware of the token type.
>>>>
>>>>                 My argument is, if the authorization server to
>>>>                 decide whether the token is valid or not (
>>>>                 irrespective of who asked the question) - AS needs
>>>>                 to know the token type - because to validate a
>>>>                 token AS should know the token type.
>>>>
>>>>                 The token type could be, bearer or MAC or any other
>>>>                 token type.
>>>>
>>>>                 Thanks & regards,
>>>>                 -Prabath
>>>>
>>>>
>>>>                 On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer
>>>>                 <jricher@mitre.org <mailto:jricher@mitre.org>> wrote:
>>>>
>>>>                     What exactly are you suggesting be added to
>>>>                     introspection? The "token_type_hint" is from
>>>>                     the client to the server, but what you've asked
>>>>                     for in terms of "token type" is from the server
>>>>                     to the client. And there was never an answer to
>>>>                     what exactly is meant by "token type" in this
>>>>                     case, particularly because you seem to want to
>>>>                     call out things like SAML and Bearer as
>>>>                     separate types.
>>>>
>>>>                      -- Justin
>>>>
>>>>
>>>>
>>>>                     On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>>>>                     I noticed that the latest Token Revocation
>>>>>                     draft [1] has introduced the parameter
>>>>>                     "token_type_hint". I would suggest the same
>>>>>                     here, as that would make what is meant by
>>>>>                     "valid" much clear..
>>>>>
>>>>>                     [1]:
>>>>>                     http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>>>>
>>>>>                     Thanks & regards,
>>>>>                     -Prabath
>>>>>
>>>>>                     On Tue, Feb 12, 2013 at 9:35 PM, Prabath
>>>>>                     Siriwardena <prabath@wso2.com
>>>>>                     <mailto:prabath@wso2.com>> wrote:
>>>>>
>>>>>                         Hi Justin,
>>>>>
>>>>>                         I doubt whether valid_token would make a
>>>>>                         difference..?
>>>>>
>>>>>                         My initial argument is what is the
>>>>>                         validation criteria..? Validation criteria
>>>>>                         depends on the token_type..
>>>>>
>>>>>                         If we are talking only about metadata -
>>>>>                         then I believe "revoked", "expired" would
>>>>>                         be more meaningful..
>>>>>
>>>>>                         Thanks & regards,
>>>>>                         -Prabath
>>>>>
>>>>>
>>>>>                         On Tue, Feb 12, 2013 at 7:53 PM, Justin
>>>>>                         Richer <jricher@mitre.org
>>>>>                         <mailto:jricher@mitre.org>> wrote:
>>>>>
>>>>>                             OK, I can see the wisdom in changing
>>>>>                             this term.
>>>>>
>>>>>                             I picked "valid" because I wanted a
>>>>>                             simple "boolean" value that would
>>>>>                             require no additional parsing or
>>>>>                             string-matching on the client's
>>>>>                             behalf, and I'd like to stick with
>>>>>                             that. OAuth is built with the
>>>>>                             assumption that clients need to be
>>>>>                             able to recover from invalid tokens at
>>>>>                             any stage, so I think a simple yes/no
>>>>>                             is the right step here.
>>>>>
>>>>>                             That said, I think you're both right
>>>>>                             that "valid" seems to have caused a
>>>>>                             bit of confusion. I don't want to go
>>>>>                             with "revoked" because I'd rather have
>>>>>                             the "token is OK" be the positive
>>>>>                             boolean value.
>>>>>
>>>>>                             Would "valid_token" be more clear? Or
>>>>>                             do we need a different adjective all
>>>>>                             together?
>>>>>
>>>>>                              -- Justin
>>>>>
>>>>>
>>>>>                             On 02/11/2013 08:02 PM, Richard
>>>>>                             Harrington wrote:
>>>>>>                             Have you considered "status" instead
>>>>>>                             of "valid"?  It could have values
>>>>>>                             like "active", "expired", and "revoked".
>>>>>>
>>>>>>                             Is it worthwhile including the status
>>>>>>                             of the client also?  For example, a
>>>>>>                             client application could be disabled,
>>>>>>                             temporarily or permanently, and thus
>>>>>>                             disabling its access tokens as well.
>>>>>>
>>>>>>
>>>>>>                             On Feb 11, 2013, at 1:56 PM, Prabath
>>>>>>                             Siriwardena <prabath@wso2.com
>>>>>>                             <mailto:prabath@wso2.com>> wrote:
>>>>>>
>>>>>>>                             I guess confusion is with 'valid'
>>>>>>>                             parameter is in the response..
>>>>>>>
>>>>>>>                             I thought this will be helpful
>>>>>>>                             to standardize the communication
>>>>>>>                             between Resource Server and the
>>>>>>>                             Authorization Server..
>>>>>>>
>>>>>>>                             I would suggest we completely remove
>>>>>>>                             "valid" from the response - or
>>>>>>>                             define it much clearly..
>>>>>>>
>>>>>>>                             May be can add "revoked" with a
>>>>>>>                             boolean attribute..
>>>>>>>
>>>>>>>                             Thanks & regards,
>>>>>>>                             -Prabath
>>>>>>>
>>>>>>>                             On Tue, Feb 12, 2013 at 3:19 AM,
>>>>>>>                             Justin Richer <jricher@mitre.org
>>>>>>>                             <mailto:jricher@mitre.org>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                 On 02/08/2013 12:51 AM, Prabath
>>>>>>>                                 Siriwardena wrote:
>>>>>>>>                                 Hi Justin,
>>>>>>>>
>>>>>>>>                                 I have couple of questions
>>>>>>>>                                 related to "valid" parameter...
>>>>>>>>
>>>>>>>>                                 This endpoint can be invoked by
>>>>>>>>                                 the Resource Server in runtime...
>>>>>>>
>>>>>>>                                 That's correct.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>                                 In that case what is exactly
>>>>>>>>                                 meant by the "resource_id" in
>>>>>>>>                                 request ?
>>>>>>>
>>>>>>>                                 The resource_id field is a
>>>>>>>                                 service-specific string that
>>>>>>>                                 basically lets the resource
>>>>>>>                                 server provide some context to
>>>>>>>                                 the request to the auth server.
>>>>>>>                                 There have been some other
>>>>>>>                                 suggestions like client IP
>>>>>>>                                 address, but I wanted to put
>>>>>>>                                 this one in because it seemed to
>>>>>>>                                 be a common theme. The client is
>>>>>>>                                 trying to do *something* with
>>>>>>>                                 the token, after all, and the
>>>>>>>                                 rights, permissions, and
>>>>>>>                                 metadata associated with the
>>>>>>>                                 token could change based on
>>>>>>>                                 that. Since the Introspection
>>>>>>>                                 endpoint is all about getting
>>>>>>>                                 that metadata back to the PR,
>>>>>>>                                 this seemed like a good idea.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>                                 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..
>>>>>>>
>>>>>>>                                 This isn't really true. The SAML
>>>>>>>                                 bearer token is fully
>>>>>>>                                 self-contained and doesn't
>>>>>>>                                 change based on other parameters
>>>>>>>                                 in the message, unlike MAC. Same
>>>>>>>                                 with JWT. When it hands a SAML
>>>>>>>                                 or JWT token to the AS, the PR
>>>>>>>                                 has given *everything* the
>>>>>>>                                 server needs to check that
>>>>>>>                                 token's validity and use.
>>>>>>>
>>>>>>>                                 MAC signatures change with every
>>>>>>>                                 message, and they're done across
>>>>>>>                                 several components of the HTTP
>>>>>>>                                 message. Therefor, the HMAC
>>>>>>>                                 check for MAC style tokens will
>>>>>>>                                 still need to be done by the
>>>>>>>                                 protected resource.
>>>>>>>                                 Introspection would help in the
>>>>>>>                                 case that the signature
>>>>>>>                                 validated just fine, but the
>>>>>>>                                 token might have expired. Or you
>>>>>>>                                 need to know what scopes apply.
>>>>>>>                                 Introspection isn't to fully
>>>>>>>                                 validate the call to the
>>>>>>>                                 protected resource -- if that
>>>>>>>                                 were the case, the PR would have
>>>>>>>                                 to send some kind of
>>>>>>>                                 encapsulated version of the
>>>>>>>                                 original request. Otherwise, the
>>>>>>>                                 AS won't have all of the
>>>>>>>                                 information it needs to check
>>>>>>>                                 the MAC.
>>>>>>>
>>>>>>>
>>>>>>>                                 I think what you're describing
>>>>>>>                                 is ultimately *not* what the
>>>>>>>                                 introspection endpoint is
>>>>>>>                                 intended to do. If that's
>>>>>>>                                 unclear from the document, can
>>>>>>>                                 you please suggest text that
>>>>>>>                                 would help clear the use case
>>>>>>>                                 up? I wouldn't want it to be
>>>>>>>                                 ambiguous.
>>>>>>>
>>>>>>>                                  -- Justin
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>                                 Thanks & regards,
>>>>>>>>                                 -Prabath
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 On Thu, Feb 7, 2013 at 10:30
>>>>>>>>                                 PM, Justin Richer
>>>>>>>>                                 <jricher@mitre.org
>>>>>>>>                                 <mailto:jricher@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
>>>>>>>>>                                     <jricher@mitre.org
>>>>>>>>>                                     <mailto:jricher@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
>>>>>>>>>>                                         <jricher@mitre.org
>>>>>>>>>>                                         <mailto:jricher@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-drafts@ietf.org>
>>>>>>>>>>                                             <mailto:internet-drafts@ietf.org>
>>>>>>>>>>
>>>>>>>>>>                                             To:
>>>>>>>>>>                                             <jricher@mitre.org>
>>>>>>>>>>                                             <mailto:jricher@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
>>>>>>>>>>                                             <mailto:OAuth@ietf.org>
>>>>>>>>>>                                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                         -- 
>>>>>>>>>>                                         Thanks & Regards,
>>>>>>>>>>                                         Prabath
>>>>>>>>>>
>>>>>>>>>>                                         Mobile : +94 71 809
>>>>>>>>>>                                         6732
>>>>>>>>>>                                         <tel:%2B94%2071%20809%206732>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                         http://blog.facilelogin.com
>>>>>>>>>>                                         http://RampartFAQ.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     -- 
>>>>>>>>>                                     Thanks & Regards,
>>>>>>>>>                                     Prabath
>>>>>>>>>
>>>>>>>>>                                     Mobile : +94 71 809 6732
>>>>>>>>>                                     <tel:%2B94%2071%20809%206732>
>>>>>>>>>
>>>>>>>>>                                     http://blog.facilelogin.com
>>>>>>>>>                                     http://RampartFAQ.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 -- 
>>>>>>>>                                 Thanks & Regards,
>>>>>>>>                                 Prabath
>>>>>>>>
>>>>>>>>                                 Mobile : +94 71 809 6732
>>>>>>>>                                 <tel:%2B94%2071%20809%206732>
>>>>>>>>
>>>>>>>>                                 http://blog.facilelogin.com
>>>>>>>>                                 http://RampartFAQ.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                             -- 
>>>>>>>                             Thanks & Regards,
>>>>>>>                             Prabath
>>>>>>>
>>>>>>>                             Mobile : +94 71 809 6732
>>>>>>>                             <tel:%2B94%2071%20809%206732>
>>>>>>>
>>>>>>>                             http://blog.facilelogin.com
>>>>>>>                             http://RampartFAQ.com
>>>>>>>                             _______________________________________________
>>>>>>>                             OAuth mailing list
>>>>>>>                             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>>                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                         -- 
>>>>>                         Thanks & Regards,
>>>>>                         Prabath
>>>>>
>>>>>                         Mobile : +94 71 809 6732
>>>>>                         <tel:%2B94%2071%20809%206732>
>>>>>
>>>>>                         http://blog.facilelogin.com
>>>>>                         http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     -- 
>>>>>                     Thanks & Regards,
>>>>>                     Prabath
>>>>>
>>>>>                     Mobile : +94 71 809 6732
>>>>>                     <tel:%2B94%2071%20809%206732>
>>>>>
>>>>>                     http://blog.facilelogin.com
>>>>>                     http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>                 -- 
>>>>                 Thanks & Regards,
>>>>                 Prabath
>>>>
>>>>                 Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>>>
>>>>                 http://blog.facilelogin.com
>>>>                 http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Thanks & Regards,
>>>>             Prabath
>>>>
>>>>             Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>>>
>>>>             http://blog.facilelogin.com
>>>>             http://RampartFAQ.com
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Thanks & Regards,
>>>         Prabath
>>>
>>>         Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>>
>>>         http://blog.facilelogin.com
>>>         http://RampartFAQ.com
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 <tel:%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