Re: [OAUTH-WG] Rechartering

Torsten Lodderstedt <> Thu, 20 October 2011 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C11221F8ACE for <>; Thu, 20 Oct 2011 15:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8OvUPZpPaHbh for <>; Thu, 20 Oct 2011 15:56:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CF8221F8ACA for <>; Thu, 20 Oct 2011 15:56:38 -0700 (PDT)
Received: from [] ( by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <>) id 1RH1XR-00049w-2V; Fri, 21 Oct 2011 00:56:37 +0200
Received: from ( []) by (Horde Framework) with HTTP; Fri, 21 Oct 2011 00:56:37 +0200
Date: Fri, 21 Oct 2011 00:56:37 +0200
Message-ID: <>
From: Torsten Lodderstedt <>
To: Hannes Tschofenig <>
References: <>
In-Reply-To: <>
User-Agent: Internet Messaging Program (IMP) H4 (5.0.14)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] Rechartering
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Oct 2011 22:56:40 -0000

Hi all,

my prioritization is driven by the goal to make OAuth the  
authorization framework of choice for any internet standard protocol,  
such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is  
missing from my point of view and explain some thoughts how to fill  
the gaps.

A standard protocol is defined in terms of resource types and messages  
by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many  
places, and used by different but deployment-independent clients.  
OAuth-based protocol specifications must also define scope values  
(e.g. read, write, send) and their relation to the resource types and  
messages. The different deployments expose the standard protocol on  
different resource server endpoints. In my opinion, it is fundamental  
to clearly distinguish scope values (standardized, static) and   
resource server addresses (deployment specific) and to manage their  
relationships. The current scope definition is much to weak and  
insufficient. Probably, the UMA concepts of hosts, resources sets, and  
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider  
before they are deployed. Would you really expect IMAP clients, e.g.  
Thunderbird, to register with any a-Mail services upfront? So clients  
should be given a way to register dynamically to the authorization  
servers. This should also allow us to cover "client instance" aspects.  
It is interesting to note, that such a mechanism would allow us to get  
rid of secret-less clients and the one-time usage requirement for  
authorization codes.

We also assume the client to know the URLs of the resource server and  
the corresponding authorization server and to use HTTPS server  
authentication to verify the resource server's authenticity. This is  
impossible in the standard scenario. Clients must be able to discover  
the authorization server a particular resource server relies on at  
runtime. The discovery mechanism could be specified by the OAuth WG,  
but could also be part of an application protocols specification. But  
we MUST find another way to prevent token phishing by counterfeit  
resource servers.

As one approach, the client could pass the (previously HTTPS  
validated) resource server's URL with the authorization request. The  
authorization server should then refuse such requests for any unknown  
(counterfeit) resource servers. Such an additional parameter could  
also serve as namespace for scope values and enable service providers  
to run multiple instances of the same service within a single  

If the additional data enlarges the request payload to much, we could  
consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard  
protocols and we will see plenty of deployments with a bunch of  
different OAuth protected resource servers. Shall this servers all be  
accessible with a single token? In my opinion, this would cause  
security, privacy and/or scalability/performance problems. To give  
just the most obvious example, the target audience of such a token  
cannot be restricted enough, which may allow a resource server (or an  
attacker in control of it) to abuse the token on other servers. But  
the current design of the code grant type forces deployments to use  
the same token for all services. What is needed from my point of view  
is a way to request and issue multiple server-specific access tokens  
with a single authorization process.

I've been advocating this topic for a long time now and I'm still  
convinced this is required to really complete the core design. We at  
Deutsche Telekom needed and implemented this function on top of the  
existing core. In my opinion, a core enhancement would be easier to  
handle and more powerful. If others support this topic, I would be  
willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should  
be given the opportunity to implement their service by utilizing  
standard server implementations. This creates the challenge to find a  
standardized protocol between authorization server and resource server  
to exchange authorization data. Depending on the token design  
(self-contained vs. handle) this could be solved by either  
standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o  
I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in  
some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration
  1) Dynamic Client Registration Protocol
  4) Client Instance Extension
- Discovery
  (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
  (depending resource server notion and multiple access tokens)

Zitat von Hannes Tschofenig <>et>:

> Hi all,
> in preparation of the upcoming IETF meeting Barry and I would like  
> to start a re-chartering discussion.  We both are currently  
> attending the Internet Identity Workshop and so we had the chance to  
> solicit input from the participants. This should serve as a  
> discussion starter.
> Potential future OAuth charter items (in random order):
> ----------------
> 1) Dynamic Client Registration Protocol
> Available document:
> 2) Token Revocation
> Available document:
> 3) UMA
> Available document:
> 4) Client Instance Extension
> Available document:
> 5) XML Encoding
> Available document:
> 6) JSON Web Token
> Available document:
> 7) JSON Web Token (JWT) Bearer Profile
> Available document:
> 8) User Experience Extension
> Available document:
> 9) Request by Reference
> Available document:
> 10) Simple Web Discovery
> Available document:
> ----------------
> We have the following questions:
> a) Are you interested in any of the above-listed items? (as a  
> reviewer, co-author, implementer, or someone who would like to  
> deploy). It is also useful to know if you think that we shouldn't  
> work on a specific item.
> b) Are there other items you would like to see the group working on?
> Note: In case your document is expired please re-submit it.
> Ciao
> Hannes & Barry
> _______________________________________________
> OAuth mailing list