Subject: Re: [OAUTH-WG] Rechartering JSON based request.

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 02 Nov 2011 20:32:08 +0100

Hi,

standard OAuth does not sign request parameters. Does this mean OAuth 
itself is not secure enough? Or is there a new threat angle against 
those parameters in the contect of Connect?

regards,
Torsten.

Am 27.10.2011 22:24, schrieb George Fletcher:
> The main reason to include the OAuth parameters in the request is to 
> ensure that the request object was not modified in transit since the 
> JSON request object can be signed. Agreed that it would be simpler if 
> OAuth adopted the JSON request style.
>
> Thanks,
> George
>
> On 10/27/11 1:33 PM, [email-masked] wrote:
>> Hi John,
>>
>> why do you need to include the OAuth request parameters into the JSON 
>> document? I would expect OpenId Connect to extend OAuth 
>> none-intrusively. This would mean to use the JSON document for OpenId 
>> connect specific parameters only. Alternatively, the JSON request 
>> style could be adopted as part of OAuth. Then, the URI request 
>> parameters could be omitted.
>>
>> regards,
>> Torsten.
>>
>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>>
>> ------------------------------------------------------------------------
>> *From: * John Bradley <[email-masked]>
>> *Date: *Thu, 27 Oct 2011 13:52:31 -0300
>> *To: *Torsten Lodderstedt<[email-masked]>
>> *Cc: *Nat Sakimura<[email-masked]>; OAuth WG<[email-masked]>
>> *Subject: *Re: [OAUTH-WG] Rechartering JSON based request.
>>
>> Hopefully to make it more compatible with existing OAuth 2 libraries. 
>>    At least leave open the possibility of dealing with it at a higher 
>> level.
>>
>> The argument has been made that you probably need to modify the 
>> library anyway to check that the duplicate parameters are a match.
>>
>> If there is consensus that the parameters should only be in the JSON 
>> then we would happily not duplicate them.
>>
>> It is mostly a case of trying to fit in to the existing OAuth work 
>> and libraries.
>>
>> John B.
>>
>> On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:
>>
>>> why is it neccessary to duplicate the OAuth request parameters?
>>>
>>> Am 27.10.2011 00:31, schrieb John Bradley:
>>>> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
>>>>
>>>> It is essentially  a standardization of the method we are using in 
>>>> openID Connect to make signed requests to the Authorization server.
>>>>
>>>> We do have the issue that parameters in the signed/encrypted 
>>>> request necessarily duplicate the query parameters to keep it a 
>>>> valid OAuth request plus an extension.
>>>>
>>>> Even if it doesn't wind up as a OAuth WG item it is probably worth 
>>>> people looking at it before the final openID spec is voted on.
>>>>
>>>> Regards
>>>> John B.
>>>>
>>>> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
>>>>
>>>>> Hi Nat,
>>>>>
>>>>> I think your proposal would be a useful OAuth enhancement. A 
>>>>> JSON-based request format would allow for more complex requests 
>>>>> (e.g. carrying resource server URLs and corresponding scope values 
>>>>> ;-)).
>>>>>
>>>>> Please note: I also think the way this mechanism is introduced and 
>>>>> used in the current OpenID connect spec requires OpenID connect 
>>>>> clients and servers to handle OAuth request parameters differently 
>>>>> than for standard OAuth requests. Introducing the JSON based claim 
>>>>> request capability to OAuth would be a way to cope with this.
>>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>
>>>>> Am 22.10.2011 16:00, schrieb Nat Sakimura:
>>>>>> Hi.
>>>>>>
>>>>>> Just a clarification:
>>>>>>
>>>>>> Although my expired draft is 'request by reference', what was 
>>>>>> proposed through it at the iiw really is a generalized JSON based 
>>>>>> claim request capability. It could be passed by value as JSON or 
>>>>>> could be passed by reference. The later is an optimization for 
>>>>>> bandwidth constrained network as well as strengthening security 
>>>>>> in some ways. This capability already exists in OpenID Connect 
>>>>>> but it is actually an underpinning transport, so it probably 
>>>>>> should belong to OAuth instead. This was the primary reason for 
>>>>>> the proposal.
>>>>>>
>>>>>> Nat
>>>>>>
>>>>>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>     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 deployment.
>>>>>>
>>>>>>     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)
>>>>>>
>>>>>>     regards,
>>>>>>     Torsten.
>>>>>>     Zitat von Hannes Tschofenig <[email-masked]
>>>>>>     <mailto:[email-masked]>>:
>>>>>>
>>>>>>
>>>>>>         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:
>>>>>>         http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/
>>>>>>
>>>>>>         2) Token Revocation
>>>>>>
>>>>>>         Available document:
>>>>>>         http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
>>>>>>
>>>>>>         3) UMA
>>>>>>
>>>>>>         Available document:
>>>>>>         http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>>>>>>
>>>>>>         4) Client Instance Extension
>>>>>>
>>>>>>         Available document:
>>>>>>         http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt
>>>>>>
>>>>>>         5) XML Encoding
>>>>>>
>>>>>>         Available document:
>>>>>>         http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt
>>>>>>
>>>>>>         6) JSON Web Token
>>>>>>
>>>>>>         Available document:
>>>>>>         http://tools.ietf.org/html/draft-jones-json-web-token-05
>>>>>>
>>>>>>         7) JSON Web Token (JWT) Bearer Profile
>>>>>>
>>>>>>         Available document:
>>>>>>         http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00
>>>>>>
>>>>>>         8) User Experience Extension
>>>>>>
>>>>>>         Available document:
>>>>>>         http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
>>>>>>
>>>>>>         9) Request by Reference
>>>>>>
>>>>>>         Available document:
>>>>>>         http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00
>>>>>>
>>>>>>         10) Simple Web Discovery
>>>>>>
>>>>>>         Available document:
>>>>>>         http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
>>>>>>
>>>>>>         ----------------
>>>>>>
>>>>>>         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
>>>>>>         [email-masked] <mailto:[email-masked]>
>>>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OAuth mailing list
>>>>>>     [email-masked] <mailto:[email-masked]>
>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Nat Sakimura (=nat)
>>>>>> Chairman, OpenID Foundation
>>>>>> http://nat.sakimura.org/
>>>>>> @_nat_en
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Wed, 2 Nov 2011 17:04:38 -0300

In the general OAuth case the user doesn't have much incentive to modify the request parameters.

In Connect the user is also authenticating to the client.  There may be cases where the user attempts to modify the request to escalate privileges.

I suspect state might be something someone would look at modifying depending on what the RP is passing.

Things that are Connect specific like authentication context requests need to be signed,  so signing the other parts at the same time is not a big deal.

When FICAM looks at OAUTH 2.0 to replace SAML attribute query,  I am betting someone is going to be looking for signed requests,m based on defence ion depth even if there are know obvious attacks.

John B.
On 2011-11-02, at 4:32 PM, Torsten Lodderstedt wrote:

> Hi,
> 
> standard OAuth does not sign request parameters. Does this mean OAuth itself is not secure enough? Or is there a new threat angle against those parameters in the contect of Connect?
> 
> regards,
> Torsten.
> 
>> The main reason to include the OAuth parameters in the request is to ensure that the request object was not modified in transit since the JSON request object can be signed. Agreed that it would be simpler if OAuth adopted the JSON request style.
>> 
>> Thanks,
>> George
>> 
>>> why do you need to include the OAuth request parameters into the JSON document? I would expect OpenId Connect to extend OAuth none-intrusively. This would mean to use the JSON document for OpenId connect specific parameters only. Alternatively, the JSON request style could be adopted as part of OAuth. Then, the URI request parameters could be omitted.
>>> 
>>> regards,
>>> Torsten.
>>> From: John Bradley <[email-masked]>
>>> Date: Thu, 27 Oct 2011 13:52:31 -0300
>>> To: Torsten Lodderstedt<[email-masked]>
>>> Cc: Nat Sakimura<[email-masked]>; OAuth WG<[email-masked]>
>>> Subject: Re: [OAUTH-WG] Rechartering JSON based request.
>>> 
>>> Hopefully to make it more compatible with existing OAuth 2 libraries.    At least leave open the possibility of dealing with it at a higher level.
>>> 
>>> The argument has been made that you probably need to modify the library anyway to check that the duplicate parameters are a match.
>>> 
>>> If there is consensus that the parameters should only be in the JSON then we would happily not duplicate them.
>>> 
>>> It is mostly a case of trying to fit in to the existing OAuth work and libraries.
>>> 
>>> John B.
>>> 
>>>>> It is essentially  a standardization of the method we are using in openID Connect to make signed requests to the Authorization server.
>>>>> 
>>>>> We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension.
>>>>> 
>>>>> Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.
>>>>> 
>>>>> Regards
>>>>> John B.
>>>>> 
>>>>>> I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)). 
>>>>>> 
>>>>>> Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.
>>>>>> 
>>>>>> regards,
>>>>>> Torsten.
>>>>>> 
>>>>>>> Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 
>>>>>>> 
>>>>>>> Nat
>>>>>>> 
>>>>>>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <[email-masked]> wrote:
>>>>>>> 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 deployment.
>>>>>>> 
>>>>>>> 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)
>>>>>>> Zitat von Hannes Tschofenig <[email-masked]>:
>>>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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?
>>>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 15 Nov 2011 10:20:35 -0700

The authoritative server could be acting as a intermediary for other authoritative servers. 

eg. RP would like to get access to both Facebook and Twitter. An intermdiate AS could acquire both tokens for the RP.

On Oct 31, 2011, at 3:56 PM, Anthony Nadalin wrote:

> Could be 2 tokens that still fulfill the same scope just that each token is a subset of the requested scope.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
> Sent: Monday, October 31, 2011 2:17 PM
> To: Dick Hardt
> Cc: OAuth WG; Dan Taflin
> Subject: Re: [OAUTH-WG] Rechartering
> 
> That's a whole different issue as this is about talking to a single server retuning two tokens with different scopes.
> 
> EHL
> 
> ________________________________________
> From: Dick Hardt [[email-masked]]
> Sent: Saturday, October 29, 2011 12:07 AM
> To: Eran Hammer-Lahav
> Cc: Dan Taflin; OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
> 
> What if the access tokens come from different authoritative servers?
> 
> On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote:
> 
>> Why not just ask for one access token with all the scopes you need, then refresh it by asking for the different subsets you want.
>> 
>> EHL
>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Dan Taflin
>>> Sent: Tuesday, October 25, 2011 3:37 PM
>>> To: OAuth WG
>>> Subject: Re: [OAUTH-WG] Rechartering
>>> 
>>> I would like to second Torsten's pitch for the ability to return 
>>> multiple access tokens with a single authorization process. The use 
>>> case for my company is to segment operations into two main 
>>> categories: protected and confidential. (A possible third category, public, would not require any authorization at all).
>>> Protected operations would be user-specific operations that don't 
>>> involve the passing of any sensitive information, such as image 
>>> search results tagged with information about whether each image is 
>>> available for download by that user. Confidential operations would 
>>> involve passing user data, like user registration or e-commerce. We 
>>> would like to protect each category of operations with distinct 
>>> tokens: a general-use token for protected operations, and a secure token for confidential operations.
>>> 
>>> We could use the scope parameter to specify either "protected" or 
>>> "confidential". Currently the oauth spec allows a Refresh token to 
>>> request a new token with reduced scope from the one originally 
>>> issued, but there is no way to obtain a new token with a completely 
>>> different scope without doing the full oauth dance a second time.
>>> 
>>> Dan
>>> 
>>> -----Original Message-----
>>> From: Torsten Lodderstedt [mailto:[email-masked]]
>>> Sent: Thursday, October 20, 2011 3:57 PM
>>> To: Hannes Tschofenig
>>> Cc: OAuth WG
>>> Subject: Re: [OAUTH-WG] Rechartering
>>> 
>>> Hi all,
>>> 
>>> 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.
>>> 
>>> 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.
>>> 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.
>>> 
>>> 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 deployment.
>>> 
>>> 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 
>>> 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 
>>> - Revocation (low hanging fruit since I-D is ready and implemented in 
>>> some
>>> places)
>>>> 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.
>>>> 
>>>> 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.
>>>>