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

From: Justin Richer <[email-masked]>
Date: Wed, 6 Feb 2013 14:24:59 -0500

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: 	<[email-masked]>
To: 	<[email-masked]>

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

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 7 Feb 2013 09:17:04 +0530

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 <[email-masked]> wrote:

> -------- Original Message --------  Subject: New Version Notification for
> draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013 11:24:20
> -0800  From: <[email-masked]> <[email-masked]>  To:
> <[email-masked]> <[email-masked]>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: Justin Richer <[email-masked]>
Date: Thu, 7 Feb 2013 10:09:30 -0500

"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:
> 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..).
>
> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>      - "scope" return parameter now follows RFC6749 format instead of
>     JSON array
>      - "subject" -> "sub", and "audience" -> "aud", to be parallel
>     with JWT claims
>     From: 	<[email-masked]> <mailto:[email-masked]>
>     To: 	<[email-masked]> <mailto:[email-masked]>
>
>
>
>     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:
>     [email-masked] <mailto:[email-masked]>

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 7 Feb 2013 21:56:28 +0530

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 <[email-masked]> wrote:

> 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
>
>
>  In the spec - in the introspection response it has the attribute "valid"
> - this is basically the validity of the token provided in the request.
>
>> -------- Original Message --------  Subject: New Version Notification
>> for draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013
>> 11:24:20 -0800  From: <[email-masked]><[email-masked]>  To:

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Thu, 7 Feb 2013 12:00:34 -0500

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 <[email-masked] 
>     "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
>
>
>>     "valid" - this is basically the validity of the token provided in
>>     the request.
>>
>>     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
>>
>>          - "scope" return parameter now follows RFC6749 format
>>         instead of JSON array
>>          - "subject" -> "sub", and "audience" -> "aud", to be
>>         parallel with JWT claims
>>         <mailto:[email-masked]>
>>     Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>

---

From: Prabath Siriwardena <[email-masked]>
Date: Fri, 8 Feb 2013 11:21:00 +0530

Hi Justin,

I have couple of questions related to "valid" parameter...

This endpoint can be invoked by the Resource Server in runtime...

In that case what is exactly meant by the "resource_id" in request ?

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..

Thanks & regards,
-Prabath

On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer <[email-masked]> wrote:

> 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.
>
> 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
>
>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Eve Maler <[email-masked]>
Date: Thu, 7 Feb 2013 21:54:46 -0800

This discussion seems to take one step into the territory that I think of as "deep" AS/RS communications. Solving token introspection all by itself means that a whole bunch of stuff must have been settled out of band/statically/in proprietary fashion. It's for this reason that UMA spec'd out "deep" communications, calling out to the token introspection spec for one "shallow" piece. The additional pieces include:

- Machine-readable AS config data that specifies the token profiles it supports (in this case, an UMA "requesting party token" profile that participates in its unique "get a token/use a token" flows)
- An MTI token profile
- An extensible mechanism for defining token profiles
- An extensible mechanism for requiring, allowing, and/or disallowing use of the token introspection endpoint for token profiles other than the MTI one

UMA calls the data associated with the token "authorization data". The spec always says "associated with", and not "contained within", since then it covers both structured and "artifact" token use cases. I've been thinking for some time that it would be useful to characterize token types/profiles along two axes: the format of the data and whether the data is locally accessible to the RS (e.g. through verifying a signature or decrypting a blob or whatever) vs. must be retrieved from the AS at run time by dereferencing an artifact. Justin, your note below hints at both of these.

I'm a bit wary of spec'ing some of the "deep" pieces in the token introspection spec unless we take a global view of what may really be required.

	Eve

On 7 Feb 2013, at 9:00 AM, Justin Richer <[email-masked]> 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
> 
>> 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
>> 
>> "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
>> 
>> 
>>> 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 
>>> 
>>>  - "scope" return parameter now follows RFC6749 format instead of JSON array
>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT claims
>>> Subject:	New Version Notification for draft-richer-oauth-introspection-02.txt

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Prabath Siriwardena <[email-masked]>
Date: Tue, 12 Feb 2013 03:00:09 +0530

Hi Justin,

Any thoughts on the following...

Thanks & regards,
-Prabath

On Fri, Feb 8, 2013 at 11:21 AM, Prabath Siriwardena <[email-masked]>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 12:54 AM, Justin Richer <[email-masked]>wrote:
>>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Mon, 11 Feb 2013 16:49:43 -0500

> 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.

> 3. The scope the token issued should match with the scope required for 
> the resource.
>
> For a MAC token...
>
> 3. The scope the token issued should match with the scope required for 
> the resource.

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 <[email-masked] 
>     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
>
>
>>     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
>>
>>         "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
>>
>>
>>>         In the spec - in the introspection response it has the
>>>         attribute "valid" - this is basically the validity of the
>>>         token provided in the request.
>>>
>>>         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
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Prabath Siriwardena <[email-masked]>
Date: Tue, 12 Feb 2013 03:26:26 +0530

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 <[email-masked]> wrote:

> 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.
>
>
>
> 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
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Richard Harrington <[email-masked]>
Date: Mon, 11 Feb 2013 17:02:23 -0800

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 <[email-masked]> wrote:

> 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..
> 
>> 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.
>> 
>> 
>>> 
>>> 3. The scope the token issued should match with the scope required for the resource.
>>> 
>>> For a MAC token...
>>> 
>>> 3. The scope the token issued should match with the scope required for the resource.
>> 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
>>> 
>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2013 09:23:30 -0500

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:
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I thought this will be helpful to standardize the communication 
>> between Resource Server and the Authorization Server..
>>
>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer <[email-masked] 
>>     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
>>     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.
>>
>>     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
>>     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
>>>         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.
>>>
>>>         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
>>>
>>>
>>>>         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
>>>>             "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
>>>>>             attribute "valid" - this is basically the validity of
>>>>>             the token provided in the request.
>>>>>
>>>>>             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
>>>>>

---

From: Prabath Siriwardena <[email-masked]>
Date: Tue, 12 Feb 2013 21:35:07 +0530

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 <[email-masked]> wrote:

> 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.
>
> 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
>
>
>  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.
>
>
>> the resource server provide some context to the request to the auth server.
>>>>  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
>>>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 14 Feb 2013 17:29:50 +0530

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 <[email-masked]>wrote:

> If we are talking only about metadata - then I believe "revoked",
> "expired" would be more meaningful..
>
> Thanks & regards,
> -Prabath
>
>
>>> 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.
>>>
>>>
>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer <[email-masked]>wrote:
>>>
>>>> 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.
>>>>
>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer <[email-masked]>wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>> -------- Original Message --------  Subject: New Version
>>>>>> Notification for draft-richer-oauth-introspection-02.txt  Date: Wed,
>>>>>> 6 Feb 2013 11:24:20 -0800  From: <[email-masked]><[email-masked]>  To:

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 09:03:22 -0500

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..
>
> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena <[email-masked] 
>     My initial argument is what is the validation criteria..?
>     Validation criteria depends on the token_type..
>
>     On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <[email-masked]
>         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
>
>
>>         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
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         I thought this will be helpful to standardize the
>>>         communication between Resource Server and the Authorization
>>>         Server..
>>>
>>>         On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer
>>>             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
>>>             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
>>>             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
>>>>
>>>>
>>>>                 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,
>>>>                 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
>>>>>                 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
>>>>>                     "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
>>>>>
>>>>>
>>>>>>                     In the spec - in the introspection response
>>>>>>                     it has the attribute "valid" - this is
>>>>>>                     basically the validity of the token provided
>>>>>>                     in the request.
>>>>>>
>>>>>>                     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
>>>>>>
>>>>>>                         <mailto:[email-masked]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     <tel:%2B94%2071%20809%206732>
>>>>>>
>>>>>                 <tel:%2B94%2071%20809%206732>
>>>>>

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 14 Feb 2013 19:52:23 +0530

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 <[email-masked]> wrote:

> "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 Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <[email-masked]>wrote:
>>
>>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer <[email-masked]>wrote:
>>>
>>>>
>>>>> token to AS? For example in the case of SAML profile - it could be SAML
>>>>> token..
>>>>>
>>>>>  Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>>> But I guess, by adding "token_type" to the request we can remove this
>>>>>> dependency.
>>>>>>
>>>>>>  WDYT..?
>>>>>>
>>>>>>  Thanks & regards,
>>>>>> -Prabath
>>>>>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 14 Feb 2013 19:55:21 +0530

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 <[email-masked]>wrote:

>>>> 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
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 09:24:51 -0500

OK, so you mean "token type" as defined by the "token_type" field coming 
back from the Token Endpoint, and *not* as defined by the 
"token_type_hint" in the revocation draft. Right?

The RO probably won't know or care about the token type. The client and 
AS have to know because they need to know how to use and provision it, 
respectively. The RS needs to know the type to be able to validate the 
call at some level.

I'm not opposed to token types being returned, I just want people to be 
very clear about what they mean by "token type" when they say it.

  -- Justin

On 02/14/2013 09:22 AM, Prabath Siriwardena wrote:
> 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.
>
> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer <[email-masked] 
>     "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
>
>
>
>>     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..
>>
>>     On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena
>>         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
>>             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
>>
>>
>>>             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.
>>>
>>>
>>>>             communication between Resource Server and the
>>>>             Authorization Server..
>>>>
>>>>                 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
>>>>                 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
>>>>>
>>>>>
>>>>>                     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.
>>>>>
>>>>>                     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
>>>>>
>>>>>
>>>>>>                     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
>>>>>>
>>>>>>                         "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
>>>>>>
>>>>>>
>>>>>>>                         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
>>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 09:25:51 -0500

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:
> 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 <[email-masked] 
>     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.
>
>         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
>
>
>
>>         introduced the parameter "token_type_hint". I would suggest
>>         the same here, as that would make what is meant by "valid"
>>         much clear..
>>
>>                 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
>>                 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.
>>
>>>                 disabled, temporarily or permanently, and thus
>>>                 disabling its access tokens as well.
>>>
>>>
>>>>                 I would suggest we completely remove "valid" from
>>>>                 the response - or define it much clearly..
>>>>
>>>>                     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.
>>>>
>>>>
>>>>>
>>>>>                     3. The scope the token issued should match
>>>>>                     with the scope required for the resource.
>>>>>
>>>>>                     For a MAC token...
>>>>>
>>>>>                     3. The scope the token issued should match
>>>>>                     with the scope required for the resource.
>>>>                     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
>>>>                     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
>>>>                     Otherwise, the AS won't have all of the
>>>>                     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
>>>>>
>>>>>
>>>>>                         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
>>>>>
>>>>>
>>>>>>                         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
>>>>>>
>>>>>>>                                 Updated introspection draft
>>>>>>>                                 based on recent comments.
>>>>>>>                                 Changes include:
>>>>>>>
>>>>>>>                                  - "scope" return parameter now
>>>>>>>                                 follows RFC6749 format instead
>>>>>>>                                 of JSON array
>>>>>>>                                 <mailto:[email-masked]>

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 14 Feb 2013 19:58:03 +0530

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 <[email-masked]> wrote:

>>  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.
>>
>>>>>> 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.
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 09:28:59 -0500

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 <[email-masked] 
>>     On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena
>>         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.
>>
>>         On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer
>>             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
>>
>>
>>
>>>             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
>>>
>>>                 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
>>>
>>>
>>>                     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
>>>
>>>
>>>>                     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.
>>>>
>>>>
>>>>>                     I would suggest we completely remove "valid"
>>>>>                     from the response - or define it much clearly..
>>>>>
>>>>>                         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
>>>>>                         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
>>>>>                         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
>>>>>                         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.
>>>>>
>>>>>
>>>>>                         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
>>>>>>
>>>>>>
>>>>>>                             It doesn't directly validate the
>>>>>>                             usage of the token, that's still up
>>>>>>                             to the PR to do that.
>>>>>>
>>>>>>                             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,
>>>>>>                             introspection endpoint will probably
>>>>>>>                             as well. BTW even in this case
>>>>>>>                             shouldn't communicate the type of
>>>>>>>                                 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
>>>>>>>
>>>>>>>
>>>>>>>>                                 I believe this is addressing
>>>>>>>>                                 one of the key missing part in
>>>>>>>>                                 OAuth 2.0...
>>>>>>>>
>>>>>>>>                                 In the spec - in the
>>>>>>>>                                 introspection response it has
>>>>>>>>                                 the attribute "valid" - this is
>>>>>>>>                                 basically the validity of the
>>>>>>>>                                 Validation criteria depends on
>>>>>>>>                                 the token and well as token
>>>>>>>>                                 type ( Bearer, MAC..).
>>>>>>>>
>>>>>>>>                                 type... But I guess, by adding
>>>>>>>>                                 "token_type" to the request we

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 14 Feb 2013 20:07:21 +0530

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.

"token was issued from here" : For this IMO we need to send an error code.
Requestor has picked the wrong AS.

The remaining is  "revoked".. That is why I proposed earlier - we better
have an attribute "revoked" - instead of "valid" in the response..

WDYT...?

Thanks & regards,
-Prabath

On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer <[email-masked]> wrote:

>>> 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.
>>>
>>> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer <[email-masked]>wrote:
>>>
>>>>>> 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.
>>>>>>
>>>>>> Have you considered "status" instead of "valid"?  It could have
>>>>>> values like "active", "expired", and "revoked".
>>>>>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 09:46:29 -0500

On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:
> 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 <[email-masked] 
>     Validity means "token was issued from here, it hasn't been
>     revoked, it hasn't expired".
>
>      -- Justin
>
>
>>     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
>>
>>>         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
>>>
>>>             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.
>>>
>>>                 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
>>>
>>>
>>>
>>>>                 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]:
>>>>                         "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.
>>>>
>>>>                         "valid" seems to have caused a bit of
>>>>                         confusion. I don't want to go with
>>>>                         "revoked" because I'd rather have the
>>>>                         Would "valid_token" be more clear? Or do we
>>>>                         need a different adjective all together?
>>>>
>>>>                          -- Justin
>>>>
>>>>
>>>>>                         "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.
>>>>>
>>>>>
>>>>>>                         I would suggest we completely remove
>>>>>>                         "valid" from the response - or define it
>>>>>>                         much clearly..
>>>>>>
>>>>>>                             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
>>>>>>                             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
>>>>>>                             several components of the HTTP
>>>>>>                             message. Therefor, the HMAC check for
>>>>>>                             MAC style tokens will still need to
>>>>>>                             be done by the protected resource.
>>>>>>                             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 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.
>>>>>>>
>>>>>>>                                 "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
>>>>>>>                                 introspection endpoint will
>>>>>>>>                                 communicate the type of token
>>>>>>>>                                 to AS? For example in the case
>>>>>>>>                                 of SAML profile - it could be
>>>>>>>>                                 SAML token..
>>>>>>>>
>>>>>>>>                                 Thanks & regards,
>>>>>>>>                                 -Prabath
>>>>>>>>
>>>>>>>>                                     "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
>>>>>>>>>                                     I believe this is
>>>>>>>>>                                     addressing one of the key
>>>>>>>>>                                     missing part in OAuth 2.0...
>>>>>>>>>
>>>>>>>>>                                     One question - I guess
>>>>>>>>>                                     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..).
>>>>>>>>>
>>>>>>>>>                                         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
>>>>>>>>>                                         To:
>>>>>>>>>                                         <[email-masked]>

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 14 Feb 2013 21:27:18 +0530

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 <[email-masked]> wrote:

>>>>> the parameter "token_type_hint". I would suggest the same here, as that
>>>>> would make what is meant by "valid" much clear..
>>>>>
>>>>> > wrote:
>>>>>>> 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.
>>>>>>>
>>>>>>>>>> attribute "valid" - this is basically the validity of the token provided in
>>>>>>>>>> the request.
>>>>>>>>>>
>>>>>>>>>> type... But I guess, by adding "token_type" to the request we can remove
>>>>>>>>>> this dependency.
>>>>>>>>>>
>>>>>>>>>>  WDYT..?
>>>>>>>>>>
>>>>>>>>>>  Thanks & regards,
>>>>>>>>>> -Prabath
>>>>>>>>>>
>>>>>>>>>> > wrote:

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 11:16:03 -0500

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:
> 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 <[email-masked] 
>>     "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 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:55 PM, Justin Richer
>>>>             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
>>>>
>>>>                 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.
>>>>
>>>>                     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
>>>>
>>>>
>>>>
>>>>>                     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]:
>>>>>                         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
>>>>>
>>>>>
>>>>>                             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.
>>>>>
>>>>>>                             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
>>>>>>>                             "valid" from the response - or
>>>>>>>                             define it much clearly..
>>>>>>>
>>>>>>>>                                 In that case what is exactly
>>>>>>>>                                 meant by the "resource_id" in
>>>>>>>>                                 request ?
>>>>>>>
>>>>>>>                                 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
>>>>>>>                                 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..
>>>>>>>>
>>>>>>>>                                 3. The scope the token issued
>>>>>>>>                                 should match with the scope
>>>>>>>>                                 required for the resource.
>>>>>>>>
>>>>>>>>                                 For a MAC token...
>>>>>>>>
>>>>>>>>                                 3. The scope the token issued
>>>>>>>>                                 should match with the scope
>>>>>>>>                                 required for the resource.
>>>>>>>                                 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.
>>>>>>>
>>>>>>>                                 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
>>>>>>>                                 encapsulated version of the
>>>>>>>                                 original request. Otherwise, the
>>>>>>>                                 AS won't have all of 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
>>>>>>>>                                     token itself in the case of
>>>>>>>>                                     Bearer or the token "id"
>>>>>>>>                                     part of something more
>>>>>>>>                                     complex like MAC. It
>>>>>>>>                                     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
>>>>>>>>                                     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,
>>>>>>>>>                                     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
>>>>>>>>>                                         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
>>>>>>>>>                                         On 02/06/2013 10:47
>>>>>>>>>                                         PM, Prabath
>>>>>>>>>                                         Siriwardena wrote:
>>>>>>>>>>                                         addressing one of the
>>>>>>>>>>                                         key missing part in
>>>>>>>>>>                                         One question - I
>>>>>>>>>>                                         guess this was
>>>>>>>>>>                                         discussed already...
>>>>>>>>>>                                         introspection
>>>>>>>>>>                                         response it has the
>>>>>>>>>>                                         attribute "valid" -
>>>>>>>>>>                                         this is basically the
>>>>>>>>>>                                         depends on the token
>>>>>>>>>>                                         and well as token
>>>>>>>>>>                                         by adding
>>>>>>>>>>                                         On Thu, Feb 7, 2013
>>>>>>>>>>                                         at 12:54 AM, Justin
>>>>>>>>>>                                         Richer
>>>>>>>>>>                                         <[email-masked]
>>>>>>>>>>                                             Updated
>>>>>>>>>>                                             introspection
>>>>>>>>>>                                             draft based on
>>>>>>>>>>                                             recent comments.
>>>>>>>>>>                                             parameter now
>>>>>>>>>>                                             follows RFC6749
>>>>>>>>>>                                             format instead of
>>>>>>>>>>                                              - "subject" ->
>>>>>>>>>>                                             "sub", and
>>>>>>>>>>                                             "audience" ->
>>>>>>>>>>                                             "aud", to be
>>>>>>>>>>                                             parallel with JWT
>>>>>>>>>>                                             Subject: 	New
>>>>>>>>>>                                             Version
>>>>>>>>>>                                             Notification for
>>>>>>>>>>                                         Mobile : +94 71 809
>>>>>>>>>>                                         6732

---

From: "Donald F Coffin" <[email-masked]>
Date: Thu, 14 Feb 2013 13:19:08 -0800

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:        <mailto:[email-masked]>
[email-masked]

From: Justin Richer [mailto:[email-masked]] 
Sent: Thursday, February 14, 2013 8:16 AM
To: Prabath Siriwardena
Cc: [email-masked]
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

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

 

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. 

 -- Justin 

WDYT...?

Thanks & regards,

-Prabath

 -- Justin 

Thanks & regards,

-Prabath

 -- Justin 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena <[email-masked]>
wrote:

Thanks & regards,

-Prabath 

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 

[1]:  <http://tools.ietf.org/html/draft-ietf-oauth-revocation-05>
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

Thanks & regards,

-Prabath

On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena <[email-masked]>
wrote:

Hi Justin, 

Thanks & regards,

-Prabath 

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. 

 -- Justin 

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.

Thanks & regards,

-Prabath

Hi Justin, 

That's correct. 

 

For a Bearer token..

For a MAC token...

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.

 -- Justin 

Thanks & regards,

-Prabath

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. 

 -- Justin 

Thanks & regards,

-Prabath

"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 

Hi Justin, 

WDYT..?

Thanks & regards,

-Prabath 

 -- Justin

-------- Original Message -------- 

Subject: 

New Version Notification for draft-richer-oauth-introspection-02.txt

Date: 

Wed, 6 Feb 2013 11:24:20 -0800

From: 

 <mailto:[email-masked]> <[email-masked]>

To: 

 <mailto:[email-masked]> <[email-masked]>

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:

 
The IETF Secretariat

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 16:23:17 -0500

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
>
> Email: [email-masked] 
> <mailto:[email-masked]>
>
> *From:*Justin Richer [mailto:[email-masked]]
> *Sent:* Thursday, February 14, 2013 8:16 AM
> *To:* Prabath Siriwardena
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Fwd: New Version Notification for 
> 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
>
>     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
>
>         "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.
>
>             to the introspection request. It can be from client to AS
>             or from RS to AS.
>
>             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
>
>
>
>                 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]:
>                 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.
>
>                     Have you considered "status" instead of "valid"?
>                      It could have values like "active", "expired",
>                     and "revoked".
>
>                     could be disabled, temporarily or permanently, and
>                         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
>                         unlike MAC. Same with JWT. When it hands a
>                         SAML or JWT token to the AS, the PR has given
>                         protected resource. Introspection would help
>                         in the case that the signature validated just
>                             says "yes this token is still good" or "no
>                             this token isn't good anymore". We could
>                             instead do this with HTTP codes or
>                                 by adding "token_type" to the request
>                                 follows RFC6749 format instead of JSON
>                                 array
>                                 *Subject: *
>                                 *Date: *
>                                 *From: *
>                                 <[email-masked]>
>                                 *To: *

---

From: Prabath Siriwardena <[email-masked]>
Date: Fri, 15 Feb 2013 03:03:13 +0530

+1 for active.

Thanks & regards,
-Prabath

On Fri, Feb 15, 2013 at 2:53 AM, Justin Richer <[email-masked]> 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:       [email-masked]****
>
> ** **
>
> *From:* Justin Richer [mailto:[email-masked] <[email-masked]>]
> draft-richer-oauth-introspection-02.txt****
>
> ** **
>
>  -- Justin****
> On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:****
>
> Not quite convinced :-) Valid has a meaning attached to that.. ****
>
> ** **
>
> - with the one you shared in this thread.****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer <[email-masked]> 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...****
>
> ** **
>
> can even be derived at the requestor's end.****
>
> ** **
>
> when it was expired, just that it has. ****
>
>
>
>
> ****
>
> ** **
>
> Requestor has picked the wrong AS.****
>
> things up. Either way it's not a good token. ****
>
>
>
>
> ****
>
> ** **
>
> have an attribute "revoked" - instead of "valid" in the response..****
>
> ** **
>
>  -- Justin ****
> ****
> ** **
> WDYT...?****
> ** **
> Thanks & regards,****
> -Prabath****
> ** **
> ** **
> On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer <[email-masked]> wrote:*
> ***
>
>  -- Justin ****
> ** **
> On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:****
>
> token ? What is meant by the validity there? ****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer <[email-masked]> wrote:*
> ***
>
>  -- Justin ****
> ** **
> On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:****
>
> introspection request. It can be from client to AS or from RS to AS. ****
>
> ** **
>
> "valid" attribute in the introspection response.****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> wrote:****
> ****
> ** **
> ****
> ** **
> 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 <[email-masked]> wrote:*
> ***
>
>  -- Justin ****
> ****
> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:****
>
> make what is meant by "valid" much clear.. ****
>
> ** **
>
> [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> wrote:****
> Hi Justin, ****
> ** **
> I doubt whether valid_token would make a difference..?****
>
> ** **
>
> criteria depends on the token_type..****
>
> ** **
>
> "expired" would be more meaningful..****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath ****
>
> ** **
>
> On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <[email-masked]> wrote:*
> ***
>
>  -- 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".****
>
> ** **
>
> disabling its access tokens as well.****
>
> ** **
>
>
> ****
>  I guess confusion is with 'valid' parameter is in the response.. ****
>
> ** **
>
> Resource Server and the Authorization Server..****
>
> ** **
>
> 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 <[email-masked]> 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 ?****
>
> ** **
>
> 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.****
>
> resource.****
> ** **
> For a MAC token...****
> ** **
> 1. Token not expired (mac id)****
>
> 2. Token should not be revoked****
>
> resource.****
> 4. HMAC check should be valid****
>
> ** **
>
> There are similar conditions for SAML bearer too..****
>
> ** **
>
>  -- Justin ****
> ****
> ** **
> Thanks & regards,****
> -Prabath****
> ** **
> ** **
> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer <[email-masked]> wrote:*
> ***
>
>  -- Justin ****
> ** **
> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:****
>
> 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 <[email-masked]> wrote:**
> **
>
>  -- 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...****
>
> ** **
>
> this is basically the validity of the token provided in the request.****
>
> ** **
>
> MAC..).****
> ** **
> ****
> ** **
> WDYT..?****
> ** **
> Thanks & regards,****
> -Prabath ****
> ** **
> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer <[email-masked]> wrote:*
> ***
>
>  -- Justin****
> -------- Original Message -------- ****
>
> *Subject: *
>
> New Version Notification for draft-richer-oauth-introspection-02.txt****
>
> *Date: *
>
> Wed, 6 Feb 2013 11:24:20 -0800****
>
> *From: *
>
> <[email-masked]> <[email-masked]>****
>
> *To: *
>
> <[email-masked]> <[email-masked]>****
>
> ** **
>
> 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****
>
> ** **
>
> ** **
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://RampartFAQ.com****
>
> ** **
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732