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

Prabath Siriwardena <prabath@wso2.com> Thu, 14 February 2013 21:33 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 2B17421F866F for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 13:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.894
X-Spam-Level:
X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.082, 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 LNFhYpg6vdnZ for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 13:33:28 -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 259D321F8654 for <oauth@ietf.org>; Thu, 14 Feb 2013 13:33:26 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so1356358eek.39 for <oauth@ietf.org>; Thu, 14 Feb 2013 13:33:26 -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=r+ERsgxzTu8h9lsFxhRiO2sQgTbpymDNz5J0gvwiOWg=; b=cYRjO6iDxIwS9kBLzKpAk+TnMy1pL3CObGrJYFaTSt5JjyABSOAM191tE7GFOLG8KB +/WFJmO8AaVFQ+Lpl8KZ7gCdsfcbByroSytSFjfO5GnaBJr5ViC6FIXJIs100lP3dL5T L3kHEkHXow7XBRpjlWf8Wf5t2HbCAwxkstKFKBAMORUNuo/HPEFMDBZ2OgrITgAIIv/O 4myn0GpnTw+WaG44i2blTZOQg5Obq4MInfunWTdPPnplKHad1aMK2AGjX5w2qU/n+CSz GtBzwOFKvoeif3HQ1731GCo31JVmEJYpKMsziJfqjT4YYA/bUtFV/en/ITk8GxZwHNMx IxAA==
MIME-Version: 1.0
X-Received: by 10.14.194.198 with SMTP id m46mr699345een.8.1360877594287; Thu, 14 Feb 2013 13:33:14 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 13:33:13 -0800 (PST)
In-Reply-To: <511D55C5.4080503@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <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> <511D0DC3.7000607@mitre.org> <00ef01ce0af8$ed591ad0$c80b5070$@reminetworks.com> <511D55C5.4080503@mitre.org>
Date: Fri, 15 Feb 2013 03:03:13 +0530
Message-ID: <CAJV9qO-sGDwQ9Lr_74K0H3-fEFwXe4P_TRLDDX+0xRjhjJR9ww@mail.gmail.com>
From: Prabath Siriwardena <prabath@wso2.com>
To: Justin Richer <jricher@mitre.org>
Content-Type: multipart/alternative; boundary="047d7b343a9e971d2f04d5b601ea"
X-Gm-Message-State: ALoCoQlEH4AvdBHEhQ2DtkpkfKbul6y9IEvoaaErrxdyHJVyfDelG4jD3tVJeDPmMU6vB+8TVddn
Cc: Donald F Coffin <donald.coffin@reminetworks.com>, 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 21:33:31 -0000

+1 for active.

Thanks & regards,
-Prabath

On Fri, Feb 15, 2013 at 2:53 AM, Justin Richer <jricher@mitre.org> wrote:

>  That could work for me. Anyone else?
>
>  -- Justin
>
> On 02/14/2013 04:19 PM, Donald F Coffin wrote:
>
>  Does the term “Active” help clarify the meaning but still confirm to
> your intention, Justin?****
>
> ** **
>
> Best regards,****
>
> Don****
>
> Donald F. Coffin****
>
> Founder/CTO****
>
> ** **
>
> REMI Networks****
>
> 22751 El Prado Suite 6216****
>
> Rancho Santa Margarita, CA  92688-3836****
>
> ** **
>
> Phone:      (949) 636-8571****
>
> Email:       donald.coffin@reminetworks.com****
>
> ** **
>
> *From:* Justin Richer [mailto:jricher@mitre.org <jricher@mitre.org>]
> *Sent:* Thursday, February 14, 2013 8:16 AM
> *To:* Prabath Siriwardena
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-richer-oauth-introspection-02.txt****
>
> ** **
>
> 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> 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
>
> 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****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
>  _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
>
> ****
>
> ** **
>
> --
> 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****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> 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****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> 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****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> 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