Re: [OAUTH-WG] Rechartering

[Anthony Nadalin <[e-mail]>]

Could be 2 tokens that still fulfill the same scope just that each token is a subset of the requested scope.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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 [[e-mail]]
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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
>> Sent: Thursday, October 20, 2011 3:57 PM
>> To: Hannes Tschofenig
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Rechartering
>>
>> 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 <[e-mail]>:
>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth