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

Justin Richer <jricher@mitre.org> Thu, 14 February 2013 14:29 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 9383921F8682 for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 06:29:49 -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 ZmR+gI+oEL0C for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 06:29:47 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1148521F8691 for <oauth@ietf.org>; Thu, 14 Feb 2013 06:29:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 917A45310DC7; Thu, 14 Feb 2013 09:29:45 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7D20E5310DC5; Thu, 14 Feb 2013 09:29:45 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:29:45 -0500
Message-ID: <511CF4AB.5010700@mitre.org>
Date: Thu, 14 Feb 2013 09:28:59 -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> <5112AE0B.1080501@mitre.org> <CAJV9qO_8-4FowrXK=ae-+xMjiJFP04ryVMLQ8SGUH8kp3PHrLg@mail.gmail.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>
In-Reply-To: <CAJV9qO8yKkrsV7d9JtDmbLY-fb5phh=ssKbEUuutkY53PgY8Vg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090306090907080103010008"
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 14:29:49 -0000

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
>
> http://blog.facilelogin.com
> http://RampartFAQ.com