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

"Donald F Coffin" <donald.coffin@reminetworks.com> Thu, 14 February 2013 21:21 UTC

Return-Path: <donald.coffin@reminetworks.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57621F8878 for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 13:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j90nmsSmi9AN for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 13:21:16 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id ECAD921F85AC for <oauth@ietf.org>; Thu, 14 Feb 2013 13:21:12 -0800 (PST)
Received: (qmail 29308 invoked by uid 0); 14 Feb 2013 21:20:47 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy2.bluehost.com with SMTP; 14 Feb 2013 21:20:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=yGlhsnnKV/15sJn8CxuxK6xLXUjs7127pCXEk7s1WD8=; b=NubQ+B31JmzYiHowWyhIV5jvNEezZVUUe3P6xeuSnzmBgJaFGXpqtMb5LReiO+3QtKTyM3lwcNes0spUGR6qFiFjasd6VgtGopel8UVuRCaBx8hknKAtA9Q2x9LUGqlq;
Received: from [68.4.207.246] (port=4202 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from <donald.coffin@reminetworks.com>) id 1U66EZ-0001TR-5O; Thu, 14 Feb 2013 14:20:47 -0700
From: Donald F Coffin <donald.coffin@reminetworks.com>
To: 'Justin Richer' <jricher@mitre.org>, 'Prabath Siriwardena' <prabath@wso2.com>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5113DDB2.7060805@mitre.org> <CAJV9qO_gM1oera9ae9sqh9n17e-ZLKuC2pmsZwhq-RmFcMyqHA@mail.gmail.com> <51196777.6000502@mitre.org> <CAJV9qO-5bWZbNUfCmaqYBQoy-qwNaSZFOsO9GL3CrbSejwVTzw@mail.gmail.com> <F6595A40-6B4E-4718-ABB5-694CA975C4DB@maymount.com> <511A5062.5010108@mitre.org> <CAJV9qO_Mr87NX=KZRqCsWasQ1FuvDNBw14eS-TcPf_KRJztQFg@mail.gmail.com> <CAJV9qO-71-sM6kXOB6Fb_bvVkDBQ5JBbs8E5X=f-K=iEmGezRA@mail.gmail.com> <511CEEAA.3030801@mitre.org> <CAJV9qO-JSXgSTkw2_pdH0D-o-xDWGDqxx=PAWYtnTj4hOQXW4Q@mail.gmail.com> <CAJV9qO9=+kiO-s7vH_ewr7XjfVdDU24F0kuif504bP53dBr1TA@mail.gmail.com> <511CF3EF.8040008@mitre.org> <CAJV9qO8yKkrsV7d9JtDmbLY-fb5phh=ssKbEUuutkY53PgY8Vg@mail.gmail.com> <511CF4AB.5010700@mitre.org> <CAJV9qO9VmjSQnWKU3kF11x35ut=AsvQ8bjuz_CKpyCScGRiA2Q@mail.gmail.com> <511CF8C5.70301@mitre.org> <CAJV9qO_-kFsWxoJwTP_RWFrb6+3frg-36JocQoo8SrpyNBMSoA@mail.gmail.com> <511D0DC3.7000607@mitre.org>
In-Reply-To: <511D0DC3.7000607@mitre.org>
Date: Thu, 14 Feb 2013 13:19:08 -0800
Message-ID: <00ef01ce0af8$ed591ad0$c80b5070$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01CE0AB5.DF3D54E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKDOKkKu6yMl3x1pM1nhfntlxrFNAIjEZUMAE2AgncDUno3igJSz0GQAgVlQCcCxP9CmwE/IqWjAg3xqC8BYatj8wLMSpeZAquJYigCgHFF8QFxkfy7AgxfqA8B+ueWagJI6UCwAQ9iy3QCP8zfgpXqvpnw
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 21:21:46 -0000

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:donald.coffin@reminetworks.com>
donald.coffin@reminetworks.com

 

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Thursday, February 14, 2013 8:16 AM
To: Prabath Siriwardena
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-richer-oauth-introspection-02.txt

 

That much I can at least do. I'd be happy with another term if there was a
good one we could drop in its place without changing the intended semantics.

 -- Justin

On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:

Not quite convinced :-) Valid has a meaning attached to that.. 

 

In case we are going ahead with this please define it clearly in the draft -
with the one you shared in this thread.

 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer <jricher@mitre.org> wrote:

 

On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:

The definition of valid is bit ambiguous in the draft...

 

Okay.. If that is the definition... and if we beak that in to parts...

 

"it hasn't expired" : In the response it self we have parameter for
issued_at and and expires_at - so whether the token is not expired or not
can even be derived at the requestor's end.

 

If the token isn't good anymore, it doesn't matter when it was issued or
when it was expired, just that it has. 






 

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

We don't know if it came from another AS or if someone's just making things
up. Either way it's not a good token. 






 

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

 

The end result of all three is the same: either the token is good, or it
isn't. I think it's much simpler and more useful to leave it at that.

 -- Justin 






 

WDYT...?

 

Thanks & regards,

-Prabath

 

 

On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer <jricher@mitre.org> wrote:

Because it will be the one that issued the token in the first place. 

Validity means "token was issued from here, it hasn't been revoked, it
hasn't expired". 

 -- Justin 

 

On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:

Okay. With out knowing the type of the token how can the AS validate the
token ? What is meant by the validity there? 

 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer <jricher@mitre.org> wrote:

OK, I don't see the utility in that at all. What would it accomplish?

 -- Justin 

 

On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:

To make it clear - my suggestion is to add token_type_hint to the
introspection request. It can be from client to AS or from RS to AS. 

 

Then AS can decide whether the provided token is valid or not and include
"valid" attribute in the introspection response.

 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena <prabath@wso2.com>
wrote:

Both the client and the resource owner should be aware of the token type. 

 

My argument is, if the authorization server to decide whether the token is
valid or not ( irrespective of who asked the question) - AS needs to know
the token type - because to validate a token AS should know the token type.

 

The token type could be, bearer or MAC or any other token type.

 

Thanks & regards,

-Prabath 

 

On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer <jricher@mitre.org> wrote:

What exactly are you suggesting be added to introspection? The
"token_type_hint" is from the client to the server, but what you've asked
for in terms of "token type" is from the server to the client. And there was
never an answer to what exactly is meant by "token type" in this case,
particularly because you seem to want to call out things like SAML and
Bearer as separate types. 

 -- Justin 





On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:

I noticed that the latest Token Revocation draft [1] has introduced the
parameter "token_type_hint". I would suggest the same here, as that would
make what is meant by "valid" much clear.. 

 

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

 

Thanks & regards,

-Prabath

On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena <prabath@wso2.com>
wrote:

Hi Justin, 

 

I doubt whether valid_token would make a difference..?

 

My initial argument is what is the validation criteria..? Validation
criteria depends on the token_type..

 

If we are talking only about metadata - then I believe "revoked", "expired"
would be more meaningful..

 

Thanks & regards,

-Prabath 

 

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jricher@mitre.org> wrote:

OK, I can see the wisdom in changing this term. 

I picked "valid" because I wanted a simple "boolean" value that would
require no additional parsing or string-matching on the client's behalf, and
I'd like to stick with that. OAuth is built with the assumption that clients
need to be able to recover from invalid tokens at any stage, so I think a
simple yes/no is the right step here. 

That said, I think you're both right that "valid" seems to have caused a bit
of confusion. I don't want to go with "revoked" because I'd rather have the
"token is OK" be the positive boolean value. 

Would "valid_token" be more clear? Or do we need a different adjective all
together?

 -- Justin 

 

On 02/11/2013 08:02 PM, Richard Harrington wrote:

Have you considered "status" instead of "valid"?  It could have values like
"active", "expired", and "revoked".

 

Is it worthwhile including the status of the client also?  For example, a
client application could be disabled, temporarily or permanently, and thus
disabling its access tokens as well.

 


On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena <prabath@wso2.com> wrote:

I guess confusion is with 'valid' parameter is in the response.. 

 

I thought this will be helpful to standardize the communication between
Resource Server and the Authorization Server..

 

I would suggest we completely remove "valid" from the response - or define
it much clearly..

 

May be can add "revoked" with a boolean attribute..

 

Thanks & regards,

-Prabath

On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer <jricher@mitre.org> wrote:

 

On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:

Hi Justin, 

 

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

 

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


That's correct. 






 

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

 

The resource_id field is a service-specific string that basically lets the
resource server provide some context to the request to the auth server.
There have been some other suggestions like client IP address, but I wanted
to put this one in because it seemed to be a common theme. The client is
trying to do *something* with the token, after all, and the rights,
permissions, and metadata associated with the token could change based on
that. Since the Introspection endpoint is all about getting that metadata
back to the PR, this seemed like a good idea. 






 

IMO a token to be valid depends on set of criteria based on it's type..

 

For a Bearer token..

 

1. Token should not be expired

2. Token should not be revoked.

3. The scope the token issued should match with the scope required for the
resource.

 

For a MAC token...

 

1. Token not expired (mac id)

2. Token should not be revoked

3. The scope the token issued should match with the scope required for the
resource.

4. HMAC check should be valid

 

There are similar conditions for SAML bearer too..

 

This isn't really true. The SAML bearer token is fully self-contained and
doesn't change based on other parameters in the message, unlike MAC. Same
with JWT. When it hands a SAML or JWT token to the AS, the PR has given
*everything* the server needs to check that token's validity and use. 

MAC signatures change with every message, and they're done across several
components of the HTTP message. Therefor, the HMAC check for MAC style
tokens will still need to be done by the protected resource. Introspection
would help in the case that the signature validated just fine, but the token
might have expired. Or you need to know what scopes apply. Introspection
isn't to fully validate the call to the protected resource -- if that were
the case, the PR would have to send some kind of encapsulated version of the
original request. Otherwise, the AS won't have all of the information it
needs to check the MAC.


I think what you're describing is ultimately *not* what the introspection
endpoint is intended to do. If that's unclear from the document, can you
please suggest text that would help clear the use case up? I wouldn't want
it to be ambiguous.

 -- Justin 






 

Thanks & regards,

-Prabath

 

 

On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer <jricher@mitre.org> wrote:

It validates the token, which would be either the token itself in the case
of Bearer or the token "id" part of something more complex like MAC. It
doesn't directly validate the usage of the token, that's still up to the PR
to do that.

I nearly added a "token type" field in this draft, but held back because
there are several kinds of "token type" that people talk about in OAuth.
First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within
Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also got
"access" vs. "refresh" and other flavors of token, like the id_token in
OpenID Connect. 

Thing is, the server running the introspection endpoint will probably know
*all* of these. But should it tell the client? If so, which of the three,
and what names should the fields be?

 -- Justin 

 

On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:

Okay.. I was thinking this could be used as a way to validate the token as
well. BTW even in this case shouldn't communicate the type of token to AS?
For example in the case of SAML profile - it could be SAML token.. 

 

Thanks & regards,

-Prabath

On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer <jricher@mitre.org> wrote:

"valid" might not be the best term, but it's meant to be a field where the
server says "yes this token is still good" or "no this token isn't good
anymore". We could instead do this with HTTP codes or something but I went
with a pure JSON response.

 -- Justin 

 

On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:

Hi Justin, 

 

I believe this is addressing one of the key missing part in OAuth 2.0...

 

One question - I guess this was discussed already...

 

In the spec - in the introspection response it has the attribute "valid" -
this is basically the validity of the token provided in the request.

 

Validation criteria depends on the token and well as token type ( Bearer,
MAC..).

 

In the spec it seems like it's coupled with Bearer token type... But I
guess, by adding "token_type" to the request we can remove this dependency.

 

WDYT..?

 

Thanks & regards,

-Prabath 

 

On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer <jricher@mitre.org> wrote:

Updated introspection draft based on recent comments. Changes include:

 - "scope" return parameter now follows RFC6749 format instead of JSON array
 - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
claims
 - clarified what happens if the authentication is bad

 -- Justin



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


Subject: 

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


Date: 

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


From: 

 <mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org>


To: 

 <mailto:jricher@mitre.org> <jricher@mitre.org>

 

A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.
 
Filename:       draft-richer-oauth-introspection
Revision:       02
Title:             OAuth Token Introspection
Creation date:       2013-02-06
WG ID:             Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:
http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
 
Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.
 
 
 

 
 
The IETF Secretariat
 

 

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>  

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

 





 

-- 
Thanks & Regards,
Prabath 

 

Mobile : +94 71 809 6732 

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