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

Prabath Siriwardena <prabath@wso2.com> Thu, 14 February 2013 15:57 UTC

Return-Path: <prabath@wso2.com>
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 56B7121F8802 for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 07:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.889
X-Spam-Level:
X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 KXWVyfBfFgRz for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 07:57:20 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 073C621F8561 for <oauth@ietf.org>; Thu, 14 Feb 2013 07:57:19 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so1304743eek.25 for <oauth@ietf.org>; Thu, 14 Feb 2013 07:57:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=wxfe81zS4yudK7Je/SdlRhMJVHkYUUdzp1n2fxNjl8Q=; b=kvZcUnlQsWDYvseRpqaBZWFVPVdGgi55T32z9Z6W0sCWTDZKf5O31QPtTCJ6RYaj82 pqvSbnrNSQbiETyWYpxAEFPUuZHXgk4jaFV8RhHeh+LJEDNh1YsLjsIGhYn7pPT8k0SM 08RwDJ19iZfTd57etXy3lQJOU2htlNF4x72K4j/SX3A2CCqEBwZp7QcO2VFG3wk52l2x jWcwlQCikglntVXB5/hy/edLwvHFCoLzhrNgpvFlyHiQ3VYDCFfwFDlakfHKRDN0ctYF VMMW8D1qdr/nrjpG1zr4aN+B2YlFAbA6TplEgv6dPHgO/nNemwaVHUBIodPVLp6eK4Ej ZJ2A==
MIME-Version: 1.0
X-Received: by 10.14.215.193 with SMTP id e41mr20568623eep.32.1360857439003; Thu, 14 Feb 2013 07:57:19 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 07:57:18 -0800 (PST)
In-Reply-To: <511CF8C5.70301@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5113C3AA.1040701@mitre.org> <CAJV9qO8BVV57eAb5kUNes15AYOpUKqw5XWQswh-FJA=b1pPgSA@mail.gmail.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>
Date: Thu, 14 Feb 2013 21:27:18 +0530
Message-ID: <CAJV9qO_-kFsWxoJwTP_RWFrb6+3frg-36JocQoo8SrpyNBMSoA@mail.gmail.com>
From: Prabath Siriwardena <prabath@wso2.com>
To: Justin Richer <jricher@mitre.org>
Content-Type: multipart/alternative; boundary="e89a8f647ac33de3d904d5b1501f"
X-Gm-Message-State: ALoCoQlIyfIMfyjun037PXg2MMp7NTmKGzBdjV3lc5bSqxbyu+8AVa4YZ2bWnQuR9cQb45WCe061
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 15:57:23 -0000

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> 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> 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> 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>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>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
>>>>> > 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>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>
>>>>>>> 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>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>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>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
>>>>>>>>>> > 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><internet-drafts@ietf.org>  To:
>>>>>>>>>>> <jricher@mitre.org> <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
>>>>>>>>>>> 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 <%2B94%2071%20809%206732>
>>>>>>>>>
>>>>>>>>> http://blog.facilelogin.com
>>>>>>>>> http://RampartFAQ.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>>>> 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 <%2B94%2071%20809%206732>
>>>>>>>
>>>>>>> http://blog.facilelogin.com
>>>>>>> http://RampartFAQ.com
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>> 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 <%2B94%2071%20809%206732>
>>>>>
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> 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 <%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