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
- [OAUTH-WG] Fwd: New Version Notification for draf… Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] New Version Notification for draft… Eve Maler
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Richard Harrington
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Donald F Coffin
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena