Re: [OAUTH-WG] Rechartering

[Eran Hammer-Lahav]

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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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:tors...@lodderstedt.net]
> 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 

Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering

[Dan Taflin]

Thanks, Bob, you're right and I withdraw my request to allow the return of two 
tokens.

However, I'm not sure OAuth supports our desired use case of passing 
"protected" access tokens over plain http, based on my reading of section 10.3: 
"Access token (as well as any access token type-specific attributes) MUST be 
kept confidential in transit and storage..." seems to imply TLS.

Dave, we may in fact end up going all SSL for our API, but that would mean 
giving up on certain advantages plain http offers, not just performance but 
also cacheability.

Dan

From: Bob Van Zant [mailto:b...@veznat.com]
Sent: Tuesday, October 25, 2011 8:41 PM
To: Dave Rochwerger
Cc: Dan Taflin; OAuth WG
Subject: Returning two tokens. Was: Re: [OAUTH-WG] Rechartering

I'm going to reiterate what has already been said.

OAuth already supports what you're trying to do. Just request a token twice, 
the first time request it with a scope or scopes that allows these special 
operations. The second time request it with a scope or scopes that do not.

In general I really like how simple OAuth 2 is. By working within the 
constraints of this simplicity we can keep the protocol simple and easy to use.

-Bob

On Tuesday, October 25, 2011, Dave Rochwerger 
mailto:da...@quizlet.com>> wrote:
> Hi Dan,
> I think we are going down the wrong path here.
> Basically, you've started with the premise of wanting plain HTTP scheme (in 
> some circumstances), which has caused you to suggest both of, firstly, 
> relaxing the only method of encryption in oauth2 and secondly, to further 
> complicate the protocol by allowing multiple tokens to be returned.
> OAuth2 (unlike version 1) has no signatures or other encryption - it relies 
> solely on SSL. Therefore any relaxation of this requirement breaks security 
> wide open (even in your specific short-term token case).
> I think you're asking the wrong question.
> We should not ask "to relax the SSL requirement", but rather - Why do you not 
> want to use SSL?
> With today's computer speeds, there is no reason not to use SSL. The plain 
> HTTP scheme does not really provide a noticeable enough performance boost. On 
> a side note, if the likes of Google's SPDY is anything to go by, the future 
> might always be SSL only anyway.
> Cheers,
> Dave
>
> On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin 
> mailto:dan.taf...@gettyimages.com>> wrote:
>
> You're right, if tracking was all we needed then a single token would 
> suffice. The reason for two tokens has more to do with the fact that we'd 
> like to allow "protected" operations to be called over plain http. This opens 
> up the possibility of an attacker intercepting the token for his own 
> nefarious use. If the only thing that token gave him access to was relatively 
> benign operations like image search, it would be an acceptable risk 
> (especially if we have a relatively short lifespan for the token).
>
>
>
> In contrast, "confidential" operations would only be callable over https. By 
> requiring a different token for them (and not allowing that token to be used 
> for unprotected operations) we prevent it from being intercepted. This design 
> intentionally mimics the way secure and non-secure http cookies work.
>
>
>
> Oauth today basically requires https for all bearer token implementations. I 
> would like to see this relaxed somewhat.
>
>
>
> Dan
>
>
>
> From: Dave Rochwerger [mailto:da...@quizlet.com]
> Sent: Tuesday, October 25, 2011 4:08 PM
> To: Dan Taflin
>
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
>
>
>
> Is separating this out into 2 different tokens, really the best way to solve 
> your use case?
>
>
>
> It sounds to me that you simply want to track/log the two types of accesses 
> differently, which can be done entirely outside of the oauth2 process.
>
> Just bucket your operations into two piles internally and track appropriately 
> (which you would have to do anyway with scopes).
>
>
>
> Scopes are the specific access that the end user grants to a 3rd party to 
> access their protected resources.
>
>
>
> When an application, to use your example, asks for the scope "protected 
> confidential", they are providing those two levels of access to the 3rd party 
> application. If the user says "allow", then that application has all the 
> access that those two scopes provides.
>
>
>
> Rather than getting applications to then further choose between two tokens to 
> simply delineate two sets of operations seems like the wrong place to be 
> doing this.
>
> i.e., why does the 3rd party application have to choose which token to use 
> for each set of operations? - the user has already granted both. The resource 
> server can do whatever tracking/logging it wants based on the actual 
> operations requested - using the single token in this case.
>
>
>
> Regards,
>
> Dave
>
>
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin 
> mailto:dan.taf...@gettyimages.com>> wrote:
>
> I would like to second Torsten's pitch fo

Re: [OAUTH-WG] Rechartering

[Torsten Lodderstedt]

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 
mailto:tors...@lodderstedt.net>> 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 f

Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering

[Torsten Lodderstedt]

Hi,

Am 26.10.2011 05:41, schrieb Bob Van Zant:

I'm going to reiterate what has already been said.

OAuth already supports what you're trying to do. Just request a token 
twice, the first time request it with a scope or scopes that allows 
these special operations. The second time request it with a scope or 
scopes that do not.


In general I really like how simple OAuth 2 is. By working within the 
constraints of this simplicity we can keep the protocol simple and 
easy to use.


I also very much like the simplicity of the protocol but is this an end 
in itself? There are use cases not supported by the protocol at present. 
I intended to point this out and raise a discussion. We did not discuss 
a solution so far, so we also don't know the impact this may cause to 
the protocol.


Justin made a proposal some month ago, which seems reasonable to me: 
http://www.ietf.org/mail-archive/web/oauth/current/msg06771.html


I think the multiple tokens use case is relevant for every multi-service 
provider.


If a client uses different services of such a provider (e.g. mail, web 
storage, telephony, and payment), there are good reasons to use 
different tokens for the respective resource servers, e.g. abuse 
prevention, service seggragation, privacy protection. This holds 
especially true if the services are operated by different business 
partners in an ASP model. The problem becomes even more obvious in cloud 
scenarios.


With the current capabilities of the authorization code, such a client 
must send the user through the OAuth dance twice or more often. 
Alternatively, a single token is good to access all service. This means 
to trade user experience for security or vice versa. I don't like this.


regards,
Torsten.



-Bob

On Tuesday, October 25, 2011, Dave Rochwerger > wrote:

> Hi Dan,
> I think we are going down the wrong path here.
> Basically, you've started with the premise of wanting plain HTTP 
scheme (in some circumstances), which has caused you to suggest both 
of, firstly, relaxing the only method of encryption in oauth2 and 
secondly, to further complicate the protocol by 
allowing multiple tokens to be returned.
> OAuth2 (unlike version 1) has no signatures or other encryption - it 
relies solely on SSL. Therefore any relaxation of this requirement 
breaks security wide open (even in your specific short-term token case).

> I think you're asking the wrong question.
> We should not ask "to relax the SSL requirement", but rather - Why 
do you not want to use SSL?
> With today's computer speeds, there is no reason not to use SSL. The 
plain HTTP scheme does not really provide a noticeable enough 
performance boost. On a side note, if the likes of Google's SPDY is 
anything to go by, the future might always be SSL only anyway.

> Cheers,
> Dave
>
> On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin 
mailto:dan.taf...@gettyimages.com>> wrote:

>
> You're right, if tracking was all we needed then a single token 
would suffice. The reason for two tokens has more to do with the fact 
that we'd like to allow "protected" operations to be called over plain 
http. This opens up the possibility of an attacker intercepting the 
token for his own nefarious use. If the only thing that token gave him 
access to was relatively benign operations like image search, it would 
be an acceptable risk (especially if we have a relatively short 
lifespan for the token).

>
>
>
> In contrast, "confidential" operations would only be callable over 
https. By requiring a different token for them (and not allowing that 
token to be used for unprotected operations) we prevent it from being 
intercepted. This design intentionally mimics the way secure and 
non-secure http cookies work.

>
>
>
> Oauth today basically requires https for all bearer token 
implementations. I would like to see this relaxed somewhat.

>
>
>
> Dan
>
>
>
> From: Dave Rochwerger [mailto:da...@quizlet.com 
]

> Sent: Tuesday, October 25, 2011 4:08 PM
> To: Dan Taflin
>
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
>
>
>
> Is separating this out into 2 different tokens, really the best way 
to solve your use case?

>
>
>
> It sounds to me that you simply want to track/log the two types of 
accesses differently, which can be done entirely outside of the oauth2 
process.

>
> Just bucket your operations into two piles internally and track 
appropriately (which you would have to do anyway with scopes).

>
>
>
> Scopes are the specific access that the end user grants to a 3rd 
party to access their protected resources.

>
>
>
> When an application, to use your example, asks for the scope 
"protected confidential", they are providing those two levels of 
access to the 3rd party application. If the user says "allow", then 
that application has all the access that those two scopes provides.

>
>
>
> Rather than getting applications to then further choose between two 
tokens to simply delineate two sets of ope

[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : OAuth 2.0 Threat Model and Security Considerations
Author(s)   : Torsten Lodderstedt
  Mark McGloin
  Phil Hunt
Filename: draft-ietf-oauth-v2-threatmodel-01.txt
Pages   : 64
Date: 2011-10-26

   This document gives security considerations based on a comprehensive
   threat model for the OAuth 2.0 Protocol.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt

[Torsten Lodderstedt]

Hi all,

the new version of the security document is mostly dedicated to the 
alignment with the core draft -22.


 * Alignment of terminology with core draft 22 (private/public client,
   redirect URI validation policy, replaced definition of the client
   categories by reference to respective core section)
 * Synchronisation with the core's security consideration section
   (UPDATE 10.12 CSRF, NEW 10.14/15)
 * Added Resource Owner Impersonation
 * Improved section 5
 * Renamed Refresh Token Replacement to Refresh Token Rotation

Thanks to all people involved!

regards,
Torsten.

Am 26.10.2011 21:11, schrieb internet-dra...@ietf.org:

A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : OAuth 2.0 Threat Model and Security Considerations
Author(s)   : Torsten Lodderstedt
   Mark McGloin
   Phil Hunt
Filename: draft-ietf-oauth-v2-threatmodel-01.txt
Pages   : 64
Date: 2011-10-26

This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] client embedded browsers (was: I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt)

[Michael Thomas]

First, I think that this threat should be elevated to something more than
a threat because it is a fundamental assumption of the protocol that the
browser is trustworthy. I have heard far too many people on this list say
that that's silly because it is "obvious" but it is not obvious to the
uninitiated, who are the remaining 7*10^9-100 people in this world.

Second, I think it's worth explicitly pointing out that this PERTAINS TO APPS
too. The world has changed significantly since OAUTH was conceived, and
native phone, etc apps continue to grow explosively after a long, long
decline leading up to OAUTH's birth. I would venture to say that a sizable
if not majority of uses of OAUTH will be in app settings.

A few inline comments:

4.1.4.  Threat: End-user credentials phished using compromised or
embedded browser

   A malicious application could attempt to phish end-user passwords by
   misusing an embedded browser in the end-user authorization process,
   or by presenting its own user-interface instead of allowing trusted
   system browser to render the authorization user interface.  By doing
   so, the usual visual trust mechanisms may be bypassed (e.g.  TLS
   confirmation, web site mechanisms).  By using an embedded or internal
   client application user interface, the client application has access
   to additional information it should not have access to (e.g. uid/
   password).


[mat] I think it's also worth mentioning either here, or in another
threat that there is a further social engineering misuse/attack where an
app offers/demands to keep your credentials so that you don't have to go
through the authorization rigmarole. Users are already conditioned to
give their credentials up to do things -- just this morning I noticed facebook
asking for my email password which they promise with sugar on top to not
store. It might be worth mentioning that things like CAPTCHA could be
deployed to defend against that sort of attack/misuse.

   Impact: If the client application or the communication is
   compromised, the user would not be aware and all information in the
   authorization exchange could be captured such as username and
   password.

   Countermeasures:

   o  Client developers and end-user can be educated to trust an
  external System-Browser only.


[mat] I assume that this is in here just for the amusement factor because
it is not a credible countermeasure.

   o  Client applications could be validated prior publication in a
  application market.

[mat] How would this be done in practice?

   o  Client developers should not collect authentication information
  directly from users and should instead use redirects to and back
  from a trusted external system-browser.


[mat] How would the resource/authentication server enforce such a thing?

The main problem here is that the countermeasures -- if they are practical at 
all --
are deep and complex problems unto themselves. To just handwave them away does
no justice to the seriousness of the threat. I realize that this strays more
into BCP land but there isn't any B-C-P, and I'm not terribly convinced
there ever will be. In that respect, I think this threat and its potential
countermeasures need to be discussed in much more detail. If there is anything
about OAUTH that will cause it to be junked, it's this threat.

Mike



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

Re: [OAUTH-WG] Phishing with Client Application Name Spoofing

[André DeMarre]

Should a brief explanation of this be added to the Threat Model and
Security Considerations document? Or does anyone even agree that this
can be a problem?

Regards,
Andre DeMarre

On Tue, Oct 4, 2011 at 11:32 AM, André DeMarre  wrote:
> I've not seen this particular variant of phishing and client
> impersonation discussed. A cursory search revealed that most of the
> related discussion centers around either (a) client impersonation with
> stolen client credentials or (b) phishing by malicious clients
> directing resource owners to spoofed authorization servers. This is
> different.
>
> This attack exploits the trust a resource owner has for an OAuth
> authorization server so as to lend repute to a malicious client
> pretending to be from a trustworthy source. This is not necessarily a
> direct vulnerability of OAuth; rather, it shows that authorization
> servers have a responsibility regarding client application names and
> how they present resource owners with the option to allow or deny
> authorization.
>
> A key to this exploit is the process of client registration with the
> authorization server. A malicious client developer registers his
> client application with a name that appears to represent a legitimate
> organization which resource owners are likely to trust. Resource
> owners at the authorization endpoint may be misled into granting
> authorization when they see the authorization server asserting " trustworthy name> is requesting permission to..."
>
> Imagine someone registers a client application with an OAuth service,
> let's call it Foobar, and he names his client app "Google, Inc.". The
> Foobar authorization server will engage the user with "Google, Inc. is
> requesting permission to do the following." The resource owner might
> reason, "I see that I'm legitimately on the https://www.foobar.com
> site, and Foobar is telling me that Google wants permission. I trust
> Foobar and Google, so I'll click Allow."
>
> To make the masquerade act even more convincing, many of the most
> popular OAuth services allow app developers to upload images which
> could be official logos of the organizations they are posing as. Often
> app developers can supply arbitrary, unconfirmed URIs which are shown
> to the resource owner as the app's website, even if the domain does
> not match the redirect URI. Some OAuth services blindly entrust client
> apps to customize the authorization page in other ways.
>
> This is hard to defend against. Authorization server administrators
> could police client names, but that approach gives them a burden
> similar to certificate authorities to verify organizations before
> issuing certificates. Very expensive.
>
> A much simpler solution is for authorization servers to be careful
> with their wording and educate resource owners about the need for
> discretion when granting authority. Foobar's message above could be
> changed: "An application calling itself Google, Inc. is requesting
> permission to do the following" later adding, "Only allow this request
> if you are sure of the application's source." Such wording is less
> likely to give the impression that the resource server is vouching for
> the application's identity.
>
> Authorization servers would also do well to show the resource owner
> additional information about the client application to help them make
> informed decisions. For example, it could display all or part of the
> app's redirect URI, saying, "The application is operating on
> example.com" or "If you decide to allow this application, your browser
> will be directed to http://www.example.com/."; Further, if the client
> app's redirect URI uses TLS (something authorization servers might
> choose to mandate), then auth servers can verify the certificate and
> show the certified organization name to resource owners.
>
> This attack is possible with OAuth 1, but OAuth 2 makes successful
> exploitation easier. OAuth 1 required the client to obtain temporary
> credentials (aka access tokens) before sending resource owners to the
> authorization endpoint. Now with OAuth 2, this attack does not require
> resource owners to interact with the client application before
> visiting the authorization server. The malicious client developer only
> needs to distribute links around the web to the authorization server's
> authorization endpoint. If the HTTP service is a social platform, the
> client app might distribute links using resource owners' accounts with
> the access tokens it has acquired, becoming a sort of worm. Continuing
> the Google/Foobar example above, it might use anchor text such as "I
> used Google Plus to synchronize with my Foobar account." Moreover, if
> the app's redirect URI bounces the resource owner back to the HTTP
> service after acquiring an authorization code, the victim will never
> see a page rendered at the insidious app's domain.
>
> This is especially dangerous because the public is not trained to
> defend against it. Savvy users are (argu

Re: [OAUTH-WG] Rechartering

[Igor Faynberg]

Actually, I think we need to document the use case.

Igor

On 10/25/2011 7:08 PM, Dave Rochwerger wrote:
Is separating this out into 2 different tokens, really the best way to 
solve your use case?


It sounds to me that you simply want to track/log the two types of 
accesses differently, which can be done entirely outside of the oauth2 
process.
Just bucket your operations into two piles internally and track 
appropriately (which you would have to do anyway with scopes).


Scopes are the specific access that the end user grants to a 3rd party 
to access their protected resources.


When an application, to use your example, asks for the scope 
"protected confidential", they are providing those two levels of 
access to the 3rd party application. If the user says "allow", then 
that application has all the access that those two scopes provides.


Rather than getting applications to then further choose between two 
tokens to simply delineate two sets of operations seems like the wrong 
place to be doing this.
i.e., why does the 3rd party application have to choose which token to 
use for each set of operations? - the user has already granted both. 
The resource server can do whatever tracking/logging it wants based on 
the actual operations requested - using the single token in this case.


Regards,
Dave

On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin 
mailto:dan.taf...@gettyimages.com>> wrote:


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:tors...@lodderstedt.net
]
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 

Re: [OAUTH-WG] Rechartering

[Nat Sakimura]

HI Torsten,

I and John just refreshed the I-D to be more in-line with what we do with
OpenID Connect.

http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01

As you point out, this would solve the duplication / non-standard behavior
that OpenID Connect requires.

Cheers,

Nat

On Thu, Oct 27, 2011 at 3:16 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> 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 <
> tors...@lodderstedt.net> 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 cont

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

[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 
>>  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

Re: [OAUTH-WG] Rechartering

[John Bradley]

The Connect use case was a bit different for needing a id_token however your 
proposal would work if being less efficient for the code flow.

However in the implicit flow you can't get a refresh token so the only option 
is to make the user go through multiple authorizations, or return multiple 
tokens.

We went with the multiple token option, by registering new response_type.

Not necessarily the perfect solution but one that works as an extension.

John B.

On 2011-10-26, at 1:15 PM, 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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:tors...@lodderstedt.net]
>> 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 s

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

[Torsten Lodderstedt]

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 
mailto:tors...@lodderstedt.net>> 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 protecte

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

[Craig McClanahan]

As a substantive comment on the draft (I'm in favor of it being a working
group item), it is not clear whether "Basic" is a required value on the
"Authorization" header included in a revocation request.  In some scenarios
(particularly three legged), the client app will not possess the username
and password of they end user -- it might only possess a currently valid
access token.  It would seem that including such a token should be a viable
authentication mechanism.

Craig McClanahan

On Fri, Sep 16, 2011 at 12:32 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

>  Hi all,
>
> I just published a new revision of the token revocation draft. We added
> JSONP support (thanks to Marius) and aligned the text with draft 21 of the
> core spec.
>
> We would like to bring this draft forward as working group item (once the
> WG is ready). We think its relevance is illustrated by the fact that this
> draft (or its predecessor) has already been implemented by Google,
> Salesforce, and Deutsche Telekom.
>
> regards,
> Torsten.
>
>  Original-Nachricht   Betreff: New Version Notification
> for draft-lodderstedt-oauth-revocation-03.txt  Datum: Fri, 16 Sep 2011
> 12:20:14 -0700  Von: internet-dra...@ietf.org  An: tors...@lodderstedt.net  
> CC:
> sdro...@gmx.de, tors...@lodderstedt.net, mscurte...@google.com
>
> A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been 
> successfully submitted by Torsten Lodderstedt and posted to the IETF 
> repository.
>
> Filename:  draft-lodderstedt-oauth-revocation
> Revision:  03
> Title: Token Revocation
> Creation date: 2011-09-16
> WG ID: Individual Submission
> Number of pages: 6
>
> Abstract:
>This draft proposes an additional endpoint for OAuth authorization
>servers for revoking tokens.
>
>
>
>
> The IETF Secretariat
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth