Subject: [OAUTH-WG] Re-Chartering: What Items to work on?

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Jan 2011 11:55:50 +0200

Hi all, 

In preparing the charter text we need your feedback. 

First, the new charter needs to include the two new items we had already accepted, namely 
* SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
* The OAuth 2.0 Protocol: Bearer Tokens
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/

In the past (around September / October 2010 timeframe) we had also discussed other proposals. See attachment below. 

We cannot just add everything to the charter because we will never be able to finish it. 
To make it more complicated there were other proposals floating around but no drafts are available (e.g. security, discovery).

It would be great to have a complete list of documents that should be considered. 
We would suggest to wait till the end of the month for new document submissions to show up. 

Then, we will start a Doodle poll to see your preference. 

Ciao
Hannes & Blaine

PS: Here are some of the other documents that people wanted to spend time on. There are more on the OAuth WG page.

* Messaging Signing
Examples: 
http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/
http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html

* User Experience Extensions
Example: 
http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/

* Artifact Binding
Example: 
http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/

* Dynamic Client Registration
Example: 
http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt

* Token Revocation:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

* Use Cases 
http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 11 Jan 2011 23:22:53 +0100

I just posted a new revision of 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/. 
Please consider it for the re-chartering process.

Additionally, Mark and me are still working on the security document. It 
takes longer time than expected because of the topic's inherent 
complexity. We plan to have a new revision ready for IETF-80.

regards,
Torsten.

Am 10.01.2011 10:55, schrieb Hannes Tschofenig:
> Hannes&  Blaine
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 12 Jan 2011 09:43:37 -0500

I don't quite understand the need for "token_type" in the request. The token being presented is going to have a type associated with it on the server -- that is, that text blob is going to have been issued by the server as an access token or a refresh token, no matter what the client claims in this request. Seems like this is at best an optional sanity check.

Unless of course you want to revoke all "related" tokens at once, in which case I think you need a different mechanism to do so.

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Torsten Lodderstedt [[email-masked]]
Sent: Tuesday, January 11, 2011 5:22 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on?

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 12 Jan 2011 22:07:39 +0100

thank you for your feedback.

So you would suggest to let the authorization server auto-detect the 
correct type?

regards,
Torsten.

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 12 Jan 2011 16:19:27 -0500

Yes, let the server do the work. In practice, it's going to be looking up the token based on the token value anyway (for bearer tokens, at least). All the client really cares about is asking to "revoke this token that I am sending you". If the client credentials and token are correct and verifiable, then the revoke should go through. A client wanting to revoke both a request token and an access token will have to make several calls to this, unless you want to put in a way to put multiple token values in. I don't recommend that though, as it seems to me an optimization for a problem nobody has yet.

 -- Justin
________________________________________
From: Torsten Lodderstedt [[email-masked]]
Sent: Wednesday, January 12, 2011 4:07 PM
To: Richer, Justin P.
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on?

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 12 Jan 2011 22:31:39 +0100

Am 12.01.2011 22:19, schrieb Richer, Justin P.:
> Yes, let the server do the work. In practice, it's going to be looking up the token based on the token value anyway (for bearer tokens, at least). All the client really cares about is asking to "revoke this token that I am sending you". If the client credentials and token are correct and verifiable, then the revoke should go through.

What do others think?

> A client wanting to revoke both a request token and an access token will have to make several calls to this, unless you want to put in a way to put multiple token values in. I don't recommend that though, as it seems to me an optimization for a problem nobody has yet.
the token_type does not control whether the server deletes all access 
tokens associated with a refresh token.

This depends on the authorization servers policy.

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 13 Jan 2011 11:39:24 -0500

On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt
<[email-masked]> wrote:
>> Yes, let the server do the work. In practice, it's going to be looking up
>> the token based on the token value anyway (for bearer tokens, at least). All
>> the client really cares about is asking to "revoke this token that I am
>> sending you". If the client credentials and token are correct and
>> verifiable, then the revoke should go through.
>
> What do others think?

I agree with Justin's suggestion, let the server figure the token
type. The server should be able to do that anyhow.

>> A client wanting to revoke both a request token and an access token will
>> have to make several calls to this, unless you want to put in a way to put
>> multiple token values in. I don't recommend that though, as it seems to me
>> an optimization for a problem nobody has yet.
>
> the token_type does not control whether the server deletes all access tokens
> associated with a refresh token.
>

There are cases when the server cannot revoke the access tokens
associated with a refresh token (static access tokens for example).
That being said, I think the server SHOULD revoke all access tokens if
possible.

Marius