Re: [OAUTH-WG] User Interface specs?

[Brent Goldman]

7.1.1. Browser-Based Attacks

This section describes common attacks against OAuth flows involving web 
browsers, as well as protections against these attacks. The flows involving web 
browsers are the Web Callback Flow, the Web Client Flow, and the Device Flow.

7.1.1.1 Phishing

Phishing is the process of a malicious website attempting to acquire sensitive 
information such as usernames and passwords by masquerading as a trustworthy 
website. With regards to OAuth, an attacker could build a malicious website 
embedding a masquerade version of an OAuth Authorization Server to obtain the 
user's credentials. The attacker could then use these credentials to authorize 
any application on the user's behalf, essentially stealing the user's identity.

For a phishing attack to be successful, the user must voluntarily enter their 
credentials into the masqueraded site. It is difficult for a user to 
distinguish between a trustworthy site and a masqueraded version if the user 
cannot see the URL bar.

7.1.1.2. Clickjacking

Clickjacking is the process of a malicious website tricking the user into 
performing undesired actions (such as authorizing an OAuth flow), without the 
user realizing this is happening, by having the user click a button that 
appears to perform an innocuous function. In more detail, a malicious site 
loads the target site in a transparent iframe overlaid on top of a set of dummy 
buttons which are carefully constructed to be placed directly under important 
buttons on the target site. When a user clicks a visible button, they are 
actually clicking a button (such as an "Authorize" button) on the hidden page.

7.1.1.3. Protection

Both phishing and clickjacking attack vectors can be avoided by disallowing 
iframes.

OAuth clients SHOULD redirect to to the Authorization Server or show the 
Authorization Server in a popup window, and SHOULD NOT display the 
Authorization Server in an iframe. In the case that a popup window is used, the 
popup window MUST display the browser's address bar.

Since malicious clients will not comply with these recommendations, OAuth 
Authorization Servers SHOULD also enforce protection. It is not possible for 
the server to determine if a browser's address bar is displayed or not, but it 
is possible for the server to protect against being displayed in an iframe.

In newer versions of Internet Explorer, Safari, and Chrome, a page is prevented 
from being iframed if the HTTP header X-FRAME-OPTION is set to DENY. If this 
header is set to SAMEORIGIN, only sites with a different origin are blocked 
from iframing the site.

For older browsers not supporting X-FRAME-OPTION, a page can be prevented from 
being iframed using JavaScript. To determine if the site is being iframed, a 
site just needs to check that top != self. If this condition is true (and if 
the top URL is not trustworthy -- e.g., it's not owned by the same domain), the 
JavaScript should redirect to an error page explaining that the site should not 
be iframed. Other options include opening the same page in a popup window, or 
showing a large DIV with high z-index covering the entire screen, preventing 
any clicks from reaching the buttons underneath.

For browsers not supporting either X-FRAME-OPTION or JavaScript, a page cannot 
be prevented from being displayed in an iframe.


On Apr 1, 2010, at 9:20 PM, Eran Hammer-Lahav wrote:

> Can you write this as an actual proposal for the text?
> 
> EHL
> 
> 
> On 4/1/10 8:25 PM, "Brent Goldman"  wrote:
> 
>> +1 on both
>> 
>> Regarding clickjacking: If we don't want the flows to be inlined in an 
>> iframe,
>> specifying that the clients must show the server in a popup doesn't protect
>> against malicious clients that choose to show it in an iframe anyway. So I
>> think it also make sense to add to the core spec that servers should protect
>> against this. The JavaScript is simple enough that perhaps the spec could 
>> give
>> an example snippet that any OAuth server to use. E.g., if (top != self &&
>> !isTopWindowSafe(top)) {
>> showBigassTransparentDivWithHighZIndex_or_redirectToErrorPage(); }.
>> 
>> -Brent
>> 
>> 
>> On Apr 1, 2010, at 5:48 PM, Allen Tom wrote:
>> 
>>> Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a
>>> popup window to the user¹s Identity Provider for user to complete the
>>> AuthZ/AuthN flow rather than taking the user away from the referring site 
>>> via
>>> a full page redirect.
>>> 
>>> In the case where a popup window is used, it¹s a very good idea to require
>>> that that the browser¹s address bar is displayed, and that an independent
>>> browser window is used, rather than an inline iframe. These requirements are
>>> needed to help prevent the user from being phished in the case where the 
>>> user
>>> has to enter their password, and to ensure that the user¹s consent was not
>>> forged via a clickjacking attack.
>>> 
>>> I believe that the Web Server Flow and the Web Client Flow will often take
>>> place w

Re: [OAUTH-WG] Draft progress update

[David Recordon]

401 seems more semantically correct, but I'm sure Eran knows the true answer. :)

+1 to this idea though. Helps client dynamically authorize users if it
turns out they didn't ask for the right scope.

On Thu, Apr 1, 2010 at 9:21 PM, Allen Tom  wrote:
> +1
>
> How about if the Protected Resource returns an HTTP 302 redirect to the Auth
> URL? The scope information can be encoded in the URL.
>
> Allen
>
>
>
> On 4/1/10 9:07 PM, "Luke Shepard"  wrote:
>
>
> On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote:
>
> If that's true, then how does the Authorization Server know what scope
> is appropriate at the Protected Resource? Does inclusion of the scope
> parameter require a 1:1 mapping between AS and PR, or at least
> communication between AS and PR?
>
> My preferred way of handling this is to have the Protected Resource throw a
> 403 Forbidden error, with an error message that specifies the scope needed -
> e.g., "oauth_scope_required=photo_read".
>
> So an app that tries to access a protected resource should be able to
> programatically take the scope in the error message and then construct an
> OAuth authorization request to get that permission from the user. Even if
> the scope is totally opaque, it should still be possible for a library to
> handle them in this way.
>
> I believe David or Eran were thinking of writing this into the spec?
>
> 
> ___
> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Eran Hammer-Lahav]

The current draft allows the following characters:

  value-char  = ALPHA / DIGIT / "-" / "." / "_" / "~" / "%"

Which means a utf-8 string will need to be encoded somehow. Should it be 
percent-encoded? Something else?

EHL


On 4/1/10 10:00 PM, "Marius Scurtescu"  wrote:

On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav  wrote:
> What is the assertion format? Binary? XML? Should the library encode it? Is
> the application using the library responsible for providing it with a
> URI-safe string?

UTF-8 string I guess, the rest should not matter.

Marius

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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Marius Scurtescu]

On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav  wrote:
> What is the assertion format? Binary? XML? Should the library encode it? Is
> the application using the library responsible for providing it with a
> URI-safe string?

UTF-8 string I guess, the rest should not matter.

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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Eran Hammer-Lahav]

What is the assertion format? Binary? XML? Should the library encode it? Is the 
application using the library responsible for providing it with a URI-safe 
string?

EHL


On 4/1/10 9:45 PM, "Marius Scurtescu"  wrote:

On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav  wrote:
> But providing a half baked flow that is short enough to just replicate where
> needed and cannot be fully implemented by generic libraries doesn't really
> offer much.

I think this is similar to the scope parameter argument, that
libraries cannot really
use an opaque scope. OAuth libraries will neither generate nor consume the
assertions, the assertion itself can be opaque. The client application needs to
obtain an assertion somehow, this is out of scope, then pass it to a library and
the library can use it as is, pass it to the Authorization Server and
deal with the
response. Works perfectly fine IMO.

Marius

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

Re: [OAUTH-WG] Scope (was: Draft progress update)

[Luke Shepard]

Sure, I don't care about the exact mechanism - although "realm" and "scope" 
don't seem equivalent concepts.

Allen - I don't think a redirect is what we want, since the Protected Resource 
is typically server-to-server, or if done in a browser then it's not in a 
user-visible screen.

On Apr 1, 2010, at 9:25 PM, Eran Hammer-Lahav wrote:

> 
> 
> 
> On 4/1/10 9:07 PM, "Luke Shepard"  wrote:
> 
>> 
>> On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote:
>>> 
>>> If that's true, then how does the Authorization Server know what scope
>>> is appropriate at the Protected Resource? Does inclusion of the scope
>>> parameter require a 1:1 mapping between AS and PR, or at least
>>> communication between AS and PR?
>> 
>> My preferred way of handling this is to have the Protected Resource throw a
>> 403 Forbidden error, with an error message that specifies the scope needed -
>> e.g., "oauth_scope_required=photo_read".
>> 
>> So an app that tries to access a protected resource should be able to
>> programatically take the scope in the error message and then construct an
>> OAuth authorization request to get that permission from the user. Even if the
>> scope is totally opaque, it should still be possible for a library to handle
>> them in this way.
>> 
>> I believe David or Eran were thinking of writing this into the spec?
>> 
> 
> How is this any better/different than plain old 401 with realm='something'.
> Why not have the client request a token capable of accessing the realm
> specified?
> 
> Before we go and invent a new mechanism that has exactly the same limited
> capabilities, we should see if the existing one can be reused or improved
> upon.
> 
> EHL
> 

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

Re: [OAUTH-WG] Device Flow - Session Fixation?

[Brent Goldman]

Those 3 sound great. Add in clickjacking protection and I think we're set.

-Brent


On Apr 1, 2010, at 9:18 PM, Allen Tom wrote:

Perhaps the best (usable) solution would be:


 1.  The approval screen must clearly indicate to the user that they should 
only be seeing that screen if they are trying to provision a device. The user 
should not have clicked on a link to get to the screen
 2.  The Auth server should also check for the presence of an HTTP Referrer. 
There should not be a referrer, since the user should not have clicked on 
anything to have landed on the screen
 3.  The Auth server must not enable “auto approval” for the device flow. 
Meaning that the user must click through the approval screen, even if the user 
had previously authorized the same client_id previously

Allen




On 4/1/10 9:06 PM, "Brent Goldman" 
> wrote:

Isn't there a similar attack for the reverse protocol? The attacker would 
socially engineer the user to give them the post-auth verification code 
displayed on the computer. This gives the attacker access to everything.

We could make this more strict by having both a device code and verification 
code. That is, have the user enter the device code into the computer, which 
would produce a verification code that needs to be entered back into the 
device. But this is susceptible to the same attack: after visiting the link 
sent by the attacker, and clicking "approve on a strange auth screen", the user 
would have to send the verification code back to the attacker. This is slightly 
better in that for an attack to be successful, the user has to communicate with 
the attacker twice instead of once.

I can't really think of a good way to eliminate the attack entirely, though.

-Brent


On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote:

Here is the note I sent a few weeks ago where we also noted the potential 
session fixation attack.  However as we noted, we are still willing to start 
with this profile and later work on where the user has to enter a code into the 
device.


-- Forwarded message --
From: Eric Sachs >
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman >
Cc: "OAuth WG (oauth@ietf.org)" 
>


Google has a similar requirement to move these types of devices to OAuth/WRAP 
and away from our older "ClientLogin" protocol where the user is prompted for 
their username/password.  The proposed profile looks fine, but we are a few 
weeks from being able to do specific work on it, so we may have more feedback 
at that time.

If the device can accept some user input, then there are some security 
advantages to requiring the user to get the code from their computer and then 
enter it into the device.  In particular, it makes it easier to protect against 
a DOS attack targeted at the service-provider to request a large # of codes.  
That method also reduces the risk of a phishing/session-fixation type attack.  
However we agree that some profile is needed for devices with no user input.  
We also expect it will be easier to get these device vendors to use a common 
industry technique, so we are fine with prioritizing our support for this 
profile.  Longer term the community could define a profile where the code is 
displayed on the computer.

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman 
> wrote:
Over the past couple days, Luke Shepard, David Recordon, and I have been 
brainstorming an OAuth profile for standardizing the flow that devices such as 
game consoles and entertainment centers use to hook up with services such as 
Netflix and iTunes. The basic flow is that a device can gain authorization by 
directing the user to visit a URL on their computer and to enter a verification 
code copied from the device's screen.

A draft spec is attached to this email. Any thoughts or feedback?

Note: this is one of the many profiles going into the OAuth 2.0 draft that 
David is writing (http://daveman692.livejournal.com/349384.html).

-Brent



___
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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Marius Scurtescu]

On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav  wrote:
> But providing a half baked flow that is short enough to just replicate where
> needed and cannot be fully implemented by generic libraries doesn’t really
> offer much.

I think this is similar to the scope parameter argument, that
libraries cannot really
use an opaque scope. OAuth libraries will neither generate nor consume the
assertions, the assertion itself can be opaque. The client application needs to
obtain an assertion somehow, this is out of scope, then pass it to a library and
the library can use it as is, pass it to the Authorization Server and
deal with the
response. Works perfectly fine IMO.

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

[OAUTH-WG] Scope (was: Draft progress update)

[Eran Hammer-Lahav]

On 4/1/10 9:07 PM, "Luke Shepard"  wrote:

> 
> On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote:
>> 
>> If that's true, then how does the Authorization Server know what scope
>> is appropriate at the Protected Resource? Does inclusion of the scope
>> parameter require a 1:1 mapping between AS and PR, or at least
>> communication between AS and PR?
> 
> My preferred way of handling this is to have the Protected Resource throw a
> 403 Forbidden error, with an error message that specifies the scope needed -
> e.g., "oauth_scope_required=photo_read".
> 
> So an app that tries to access a protected resource should be able to
> programatically take the scope in the error message and then construct an
> OAuth authorization request to get that permission from the user. Even if the
> scope is totally opaque, it should still be possible for a library to handle
> them in this way.
> 
> I believe David or Eran were thinking of writing this into the spec?
> 

How is this any better/different than plain old 401 with realm='something'.
Why not have the client request a token capable of accessing the realm
specified?

Before we go and invent a new mechanism that has exactly the same limited
capabilities, we should see if the existing one can be reused or improved
upon.

EHL

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

Re: [OAUTH-WG] Draft progress update

[Allen Tom]

+1

How about if the Protected Resource returns an HTTP 302 redirect to the Auth
URL? The scope information can be encoded in the URL.

Allen



On 4/1/10 9:07 PM, "Luke Shepard"  wrote:

> 
> On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote:
>> 
>> If that's true, then how does the Authorization Server know what scope
>> is appropriate at the Protected Resource? Does inclusion of the scope
>> parameter require a 1:1 mapping between AS and PR, or at least
>> communication between AS and PR?
> 
> My preferred way of handling this is to have the Protected Resource throw a
> 403 Forbidden error, with an error message that specifies the scope needed -
> e.g., "oauth_scope_required=photo_read".
> 
> So an app that tries to access a protected resource should be able to
> programatically take the scope in the error message and then construct an
> OAuth authorization request to get that permission from the user. Even if the
> scope is totally opaque, it should still be possible for a library to handle
> them in this way.
> 
> I believe David or Eran were thinking of writing this into the spec?
> 
> 
> ___
> 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

Re: [OAUTH-WG] User Interface specs?

[Eran Hammer-Lahav]

Can you write this as an actual proposal for the text?

EHL


On 4/1/10 8:25 PM, "Brent Goldman"  wrote:

> +1 on both
> 
> Regarding clickjacking: If we don't want the flows to be inlined in an iframe,
> specifying that the clients must show the server in a popup doesn't protect
> against malicious clients that choose to show it in an iframe anyway. So I
> think it also make sense to add to the core spec that servers should protect
> against this. The JavaScript is simple enough that perhaps the spec could give
> an example snippet that any OAuth server to use. E.g., if (top != self &&
> !isTopWindowSafe(top)) {
> showBigassTransparentDivWithHighZIndex_or_redirectToErrorPage(); }.
> 
> -Brent
> 
> 
> On Apr 1, 2010, at 5:48 PM, Allen Tom wrote:
> 
>> Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a
>> popup window to the user¹s Identity Provider for user to complete the
>> AuthZ/AuthN flow rather than taking the user away from the referring site via
>> a full page redirect.
>> 
>> In the case where a popup window is used, it¹s a very good idea to require
>> that that the browser¹s address bar is displayed, and that an independent
>> browser window is used, rather than an inline iframe. These requirements are
>> needed to help prevent the user from being phished in the case where the user
>> has to enter their password, and to ensure that the user¹s consent was not
>> forged via a clickjacking attack.
>> 
>> I believe that the Web Server Flow and the Web Client Flow will often take
>> place within a popup window, so it would make sense to put into the core spec
>> that popups should be independent browser windows with the address bar
>> clearly displayed.
>> 
>> Another missing feature in the core spec is support for multiple languages.
>> Given that many Service Providers have a global userbase, client applications
>> will want to have a way to specify the language to be used on the auth
>> screen. While the User Agent¹s Accept-Language: HTTP header, as well as the
>> user¹s IP address could be used as language hints, in practice clients will
>> want the ability to specify the language.
>> 
>> Is there consensus to get Popup Window requirements and language support into
>> the OAuth2 core spec?
>> 
>> Allen
>> 
> 
> 

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

Re: [OAUTH-WG] Device Flow - Session Fixation?

[Allen Tom]

Perhaps the best (usable) solution would be:

1. The approval screen must clearly indicate to the user that they should
only be seeing that screen if they are trying to provision a device. The
user should not have clicked on a link to get to the screen
2. The Auth server should also check for the presence of an HTTP Referrer.
There should not be a referrer, since the user should not have clicked on
anything to have landed on the screen
3. The Auth server must not enable ³auto approval² for the device flow.
Meaning that the user must click through the approval screen, even if the
user had previously authorized the same client_id previously

Allen




On 4/1/10 9:06 PM, "Brent Goldman"  wrote:

> Isn't there a similar attack for the reverse protocol? The attacker would
> socially engineer the user to give them the post-auth verification code
> displayed on the computer. This gives the attacker access to everything.
> 
> We could make this more strict by having both a device code and verification
> code. That is, have the user enter the device code into the computer, which
> would produce a verification code that needs to be entered back into the
> device. But this is susceptible to the same attack: after visiting the link
> sent by the attacker, and clicking "approve on a strange auth screen", the
> user would have to send the verification code back to the attacker. This is
> slightly better in that for an attack to be successful, the user has to
> communicate with the attacker twice instead of once.
> 
> I can't really think of a good way to eliminate the attack entirely, though.
> 
> -Brent
> 
> 
> On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote:
> 
>> Here is the note I sent a few weeks ago where we also noted the potential
>> session fixation attack.  However as we noted, we are still willing to start
>> with this profile and later work on where the user has to enter a code into
>> the device.
>> 
>> 
>> -- Forwarded message --
>> From: Eric Sachs 
>> Date: Wed, Mar 17, 2010 at 5:45 PM
>> Subject: Re: [OAUTH-WG] Device Profile
>> To: Brent Goldman 
>> Cc: "OAuth WG (oauth@ietf.org)" 
>> 
>> 
>> Google has a similar requirement to move these types of devices to OAuth/WRAP
>> and away from our older "ClientLogin" protocol where the user is prompted for
>> their username/password.  The proposed profile looks fine, but we are a few
>> weeks from being able to do specific work on it, so we may have more feedback
>> at that time.
>> 
>> If the device can accept some user input, then there are some security
>> advantages to requiring the user to get the code from their computer and then
>> enter it into the device.  In particular, it makes it easier to protect
>> against a DOS attack targeted at the service-provider to request a large # of
>> codes.  That method also reduces the risk of a phishing/session-fixation type
>> attack.  However we agree that some profile is needed for devices with no
>> user input.  We also expect it will be easier to get these device vendors to
>> use a common industry technique, so we are fine with prioritizing our support
>> for this profile.  Longer term the community could define a profile where the
>> code is displayed on the computer.
>> 
>> On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman  wrote:
>>> Over the past couple days, Luke Shepard, David Recordon, and I have been
>>> brainstorming an OAuth profile for standardizing the flow that devices such
>>> as game consoles and entertainment centers use to hook up with services such
>>> as Netflix and iTunes. The basic flow is that a device can gain
>>> authorization by directing the user to visit a URL on their computer and to
>>> enter a verification code copied from the device's screen.
>>> 
>>> A draft spec is attached to this email. Any thoughts or feedback?
>>> 
>>> Note: this is one of the many profiles going into the OAuth 2.0 draft that
>>> David is writing (http://daveman692.livejournal.com/349384.html).
>>> 
>>> -Brent
>>> 
>>> 
>>> 
>>> ___
>>> 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

Re: [OAUTH-WG] Re-scoping OAuth access tokens

[Eran Hammer-Lahav]

Only the access token (or refresh token) represents the access grant (which
includes scope). To extend the scope of an already granted authorization,
the client must use the access token or refresh token to do so.

EHL


On 4/1/10 8:15 PM, "Allen Tom"  wrote:

> Hi George -
> 
> I¹m trying to figure out the re-scoping flow as well, to allow clients to
> progressively upgrade their scopes over time.
> 
> A potential pitfall is the scenario where multiple clients, share the same
> client_id and secret. For instance, a developer might have both a website and
> also an iphone app, and reuses the same client_id for both.
> 
> Should the Service Provider keep the scopes in sync for both apps? If the
> refresh_token is not passed to the re-auth flow, the Service Provider will
> have a hard time determining which instance of the app is requesting the
> upgraded scope.
> 
> Perhaps this doesn't matter, because it can be argued that although there
> might be multiple instances of the same client_id, it¹s all the same app
> anyway. So maybe it¹s OK to upgrade the scopes for all instances of a given
> client_id.
> 
> Allen
> 
> On 3/26/10 10:57 AM, "George Fletcher"  wrote:
> 
>> 
>> 
>> It it sufficient for the client to just start a new web server flow and
>> specify a new scope parameter that includes both "read buddylist" and "send
>> IM"? The AS would then show Alice that she'd already approved "read
>> buddylist" and just needed to approve "send IM"? This requires the client to
>> keep track of all scopes requested for a given user:protected_resource.
>> 
>> Another option might be to just allow the client to pass in the refresh_token
>> (as that likely has the scoped embedded/associated with it). In this case the
>> client could just ask for the new scope it wanted.
>> 
>> Thoughts?  Anyone else have a need for dynamic re-scoping?
>> 
>> Thanks,
>> George
>> 
>> P.S. This flow is deployedas part of the AOL IM APIs. However, when
>> dynamically adding an authorization, we only show the user what their being
>> asked to consent to, not what they've done in the past.
>> 
>> 
>> 
>> ___
>> 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] Scope (was: Draft progress update)

[Eran Hammer-Lahav]

On 4/1/10 8:13 PM, "Peter Saint-Andre"  wrote:

> On 4/1/10 8:21 PM, Allen Tom wrote:
>> The way we do this at Yahoo is that the developer must indicate what scopes
>> they want to access when registering for a client_identifier/secret.
>> 
>> Although we've done it this way for several years, we've gotten plenty of
>> feedback that client developers want the flexibility to specify the scopes
>> at user authorization time.
> 
> OK, so the scope is something that the [developer of a] Client
> establishes beforehand with the Authorization Service. But that still
> doesn't tell us what a scope is. Does someone have a definition?

There isn't one - its service specific.

The easy ones are:

Duration
List of protected resources, URI wildcard, or name of protected segment
Read/write access or HTTP methods

3 years ago when we dropped the scope/token_attributes parameter from the
spec we decided to bring it back when we have enough deployment experience.
I strongly believe this rule still holds.

It would be great if those with OAuth 1.0a deployments can share how they
specify scope.

EHL

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

Re: [OAUTH-WG] User Interface specs?

[Eran Hammer-Lahav]

On 4/1/10 5:48 PM, "Allen Tom"  wrote:

> Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a
> popup window to the user¹s Identity Provider for user to complete the
> AuthZ/AuthN flow rather than taking the user away from the referring site via
> a full page redirect.
> 
> In the case where a popup window is used, it¹s a very good idea to require
> that that the browser¹s address bar is displayed, and that an independent
> browser window is used, rather than an inline iframe. These requirements are
> needed to help prevent the user from being phished in the case where the user
> has to enter their password, and to ensure that the user¹s consent was not
> forged via a clickjacking attack.
> 
> I believe that the Web Server Flow and the Web Client Flow will often take
> place within a popup window, so it would make sense to put into the core spec
> that popups should be independent browser windows with the address bar clearly
> displayed. 

It certainly belongs in the security considerations section, but unless
there is a way for the server to enforce it, a MUST directive is pointless.
An attacker will obviously not comply...

> Another missing feature in the core spec is support for multiple languages.
> Given that many Service Providers have a global userbase, client applications
> will want to have a way to specify the language to be used on the auth screen.
> While the User Agent¹s Accept-Language: HTTP header, as well as the user¹s IP
> address could be used as language hints, in practice clients will want the
> ability to specify the language.
> 
> Is there consensus to get Popup Window requirements and language support into
> the OAuth2 core spec?

Don't ask. Write a proposal and send to the list for each of these items
(don't spend time on editorial or language). I'll add it to the spec and
we'll see how well it fits in. At this stage we should be liberal in what we
include so we can get the full picture. Then we will decide what to drop or
spin-off.

EHL

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

Re: [OAUTH-WG] Draft progress update

[Luke Shepard]

On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote:

If that's true, then how does the Authorization Server know what scope
is appropriate at the Protected Resource? Does inclusion of the scope
parameter require a 1:1 mapping between AS and PR, or at least
communication between AS and PR?

My preferred way of handling this is to have the Protected Resource throw a 403 
Forbidden error, with an error message that specifies the scope needed - e.g., 
"oauth_scope_required=photo_read".

So an app that tries to access a protected resource should be able to 
programatically take the scope in the error message and then construct an OAuth 
authorization request to get that permission from the user. Even if the scope 
is totally opaque, it should still be possible for a library to handle them in 
this way.

I believe David or Eran were thinking of writing this into the spec?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Device Flow - Session Fixation?

[Brent Goldman]

Isn't there a similar attack for the reverse protocol? The attacker would 
socially engineer the user to give them the post-auth verification code 
displayed on the computer. This gives the attacker access to everything.

We could make this more strict by having both a device code and verification 
code. That is, have the user enter the device code into the computer, which 
would produce a verification code that needs to be entered back into the 
device. But this is susceptible to the same attack: after visiting the link 
sent by the attacker, and clicking "approve on a strange auth screen", the user 
would have to send the verification code back to the attacker. This is slightly 
better in that for an attack to be successful, the user has to communicate with 
the attacker twice instead of once.

I can't really think of a good way to eliminate the attack entirely, though.

-Brent


On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote:

Here is the note I sent a few weeks ago where we also noted the potential 
session fixation attack.  However as we noted, we are still willing to start 
with this profile and later work on where the user has to enter a code into the 
device.


-- Forwarded message --
From: Eric Sachs mailto:esa...@google.com>>
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman mailto:br...@facebook.com>>
Cc: "OAuth WG (oauth@ietf.org)" 
mailto:oauth@ietf.org>>


Google has a similar requirement to move these types of devices to OAuth/WRAP 
and away from our older "ClientLogin" protocol where the user is prompted for 
their username/password.  The proposed profile looks fine, but we are a few 
weeks from being able to do specific work on it, so we may have more feedback 
at that time.

If the device can accept some user input, then there are some security 
advantages to requiring the user to get the code from their computer and then 
enter it into the device.  In particular, it makes it easier to protect against 
a DOS attack targeted at the service-provider to request a large # of codes.  
That method also reduces the risk of a phishing/session-fixation type attack.  
However we agree that some profile is needed for devices with no user input.  
We also expect it will be easier to get these device vendors to use a common 
industry technique, so we are fine with prioritizing our support for this 
profile.  Longer term the community could define a profile where the code is 
displayed on the computer.

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman 
mailto:br...@facebook.com>> wrote:
Over the past couple days, Luke Shepard, David Recordon, and I have been 
brainstorming an OAuth profile for standardizing the flow that devices such as 
game consoles and entertainment centers use to hook up with services such as 
Netflix and iTunes. The basic flow is that a device can gain authorization by 
directing the user to visit a URL on their computer and to enter a verification 
code copied from the device's screen.

A draft spec is attached to this email. Any thoughts or feedback?

Note: this is one of the many profiles going into the OAuth 2.0 draft that 
David is writing (http://daveman692.livejournal.com/349384.html).

-Brent



___
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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Eran Hammer-Lahav]

This boils down to: if the flow cannot be used without further profile, and it 
is less than a page long, what's the value of putting it in the specification, 
as opposed to a fully specified extension? Or the alternative to provide one 
fully specified flow using the most common type of assertions (I'm not a SAML 
expert so I have no clue what that might be), and let others use that as a 
template.

But providing a half baked flow that is short enough to just replicate where 
needed and cannot be fully implemented by generic libraries doesn't really 
offer much.

I am not putting a stake in the ground on this but I am doing my job as editor 
to point out to the authors and users of this spec that as written, the flow is 
just not actually useful. It has the same value as if I posted it on my blog 
because to use it, someone will have to write a new spec that profiles it to an 
interop-capable setup.

EHL


On 4/1/10 5:16 PM, "Brian Eaton"  wrote:

On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer-Lahav  wrote:
> Are they profiling a half page spec?

The spec is 66 pages long.  But the widely used pieces are quite a bit
shorter. =)

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

Re: [OAUTH-WG] User Interface specs?

[Brent Goldman]

+1 on both

Regarding clickjacking: If we don't want the flows to be inlined in an iframe, 
specifying that the clients must show the server in a popup doesn't protect 
against malicious clients that choose to show it in an iframe anyway. So I 
think it also make sense to add to the core spec that servers should protect 
against this. The JavaScript is simple enough that perhaps the spec could give 
an example snippet that any OAuth server to use. E.g., if (top != self && 
!isTopWindowSafe(top)) { 
showBigassTransparentDivWithHighZIndex_or_redirectToErrorPage(); }.

-Brent


On Apr 1, 2010, at 5:48 PM, Allen Tom wrote:

Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a popup 
window to the user’s Identity Provider for user to complete the AuthZ/AuthN 
flow rather than taking the user away from the referring site via a full page 
redirect.

In the case where a popup window is used, it’s a very good idea to require that 
that the browser’s address bar is displayed, and that an independent browser 
window is used, rather than an inline iframe. These requirements are needed to 
help prevent the user from being phished in the case where the user has to 
enter their password, and to ensure that the user’s consent was not forged via 
a clickjacking attack.

I believe that the Web Server Flow and the Web Client Flow will often take 
place within a popup window, so it would make sense to put into the core spec 
that popups should be independent browser windows with the address bar clearly 
displayed.

Another missing feature in the core spec is support for multiple languages. 
Given that many Service Providers have a global userbase, client applications 
will want to have a way to specify the language to be used on the auth screen. 
While the User Agent’s Accept-Language: HTTP header, as well as the user’s IP 
address could be used as language hints, in practice clients will want the 
ability to specify the language.

Is there consensus to get Popup Window requirements and language support into 
the OAuth2 core spec?

Allen


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

Re: [OAUTH-WG] Re-scoping OAuth access tokens

[Allen Tom]

Hi George -

I¹m trying to figure out the re-scoping flow as well, to allow clients to
progressively upgrade their scopes over time.

A potential pitfall is the scenario where multiple clients, share the same
client_id and secret. For instance, a developer might have both a website
and also an iphone app, and reuses the same client_id for both.

Should the Service Provider keep the scopes in sync for both apps? If the
refresh_token is not passed to the re-auth flow, the Service Provider will
have a hard time determining which instance of the app is requesting the
upgraded scope.

Perhaps this doesn't matter, because it can be argued that although there
might be multiple instances of the same client_id, it¹s all the same app
anyway. So maybe it¹s OK to upgrade the scopes for all instances of a given
client_id.

Allen

On 3/26/10 10:57 AM, "George Fletcher"  wrote:

> 
> 
> It it sufficient for the client to just start a new web server flow and
> specify a new scope parameter that includes both "read buddylist" and "send
> IM"? The AS would then show Alice that she'd already approved "read buddylist"
> and just needed to approve "send IM"? This requires the client to keep track
> of all scopes requested for a given user:protected_resource.
> 
> Another option might be to just allow the client to pass in the refresh_token
> (as that likely has the scoped embedded/associated with it). In this case the
> client could just ask for the new scope it wanted.
> 
> Thoughts?  Anyone else have a need for dynamic re-scoping?
> 
> Thanks,
> George
> 
> P.S. This flow is deployedas part of the AOL IM APIs. However, when
> dynamically adding an authorization, we only show the user what their being
> asked to consent to, not what they've done in the past.
> 
> 
> 
> ___
> 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

Re: [OAUTH-WG] Draft progress update

[Peter Saint-Andre]

On 4/1/10 8:21 PM, Allen Tom wrote:
> The way we do this at Yahoo is that the developer must indicate what scopes
> they want to access when registering for a client_identifier/secret.
> 
> Although we've done it this way for several years, we've gotten plenty of
> feedback that client developers want the flexibility to specify the scopes
> at user authorization time.

OK, so the scope is something that the [developer of a] Client
establishes beforehand with the Authorization Service. But that still
doesn't tell us what a scope is. Does someone have a definition?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Device Flow - Session Fixation?

[Eric Sachs]

Here is the note I sent a few weeks ago where we also noted the potential
session fixation attack.  However as we noted, we are still willing to start
with this profile and later work on where the user has to enter a code into
the device.


-- Forwarded message --
From: Eric Sachs 
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman 
Cc: "OAuth WG (oauth@ietf.org)" 


Google has a similar requirement to move these types of devices to
OAuth/WRAP and away from our older "ClientLogin" protocol where the user is
prompted for their username/password.  The proposed profile looks fine, but
we are a few weeks from being able to do specific work on it, so we may have
more feedback at that time.

If the device can accept some user input, then there are some security
advantages to requiring the user to get the code from their computer and
then enter it into the device.  In particular, it makes it easier to protect
against a DOS attack targeted at the service-provider to request a large #
of codes.  That method also reduces the risk of a phishing/session-fixation
type attack.  However we agree that some profile is needed for devices with
no user input.  We also expect it will be easier to get these device vendors
to use a common industry technique, so we are fine with prioritizing our
support for this profile.  Longer term the community could define a profile
where the code is displayed on the computer.

On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman  wrote:

> Over the past couple days, Luke Shepard, David Recordon, and I have been
> brainstorming an OAuth profile for standardizing the flow that devices such
> as game consoles and entertainment centers use to hook up with services such
> as Netflix and iTunes. The basic flow is that a device can gain
> authorization by directing the user to visit a URL on their computer and to
> enter a verification code copied from the device's screen.
>
> A draft spec is attached to this email. Any thoughts or feedback?
>
> Note: this is one of the many profiles going into the OAuth 2.0 draft that
> David is writing (http://daveman692.livejournal.com/349384.html).
>
> -Brent
>
>
>
> ___
> 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] Device Flow - Session Fixation?

[Allen Tom]

Longtime fans of Oauth will remember the Session Fixation security issue we
had last year.

The Device Flow specified in the OAuth2 draft seems to have the same issue.

To illustrate:

Imagine that a Photos Hosting Service supports OAuth2, and supports the
Device Flow for Internet enabled picture frames. These devices have screens,
but no browser, and no keyboard.

An Attacker sets up his picture frame, and is instructed to use a browser on
a separate device to authorize the picture frame. However, rather than
entering oauth_verification_url on his own browser he instead socially
engineers a victim to do it. (this is essentially the same thing as
phishing)

The Attacker IMs  or emails the victim the link to the Auth url ­ depending
on how the Auth Flow is implemented, the attacker might even be able to
construct the auth url with the oauth_user_code appended as a query
parameter. If the victim is persuaded to click the link and approve the auth
request, the Attacker will then have access to the victim¹s photos.

Again, this is social engineering, and the victim has to be persuaded to
click on an untrusted link and to click ³approve² on a strange auth screen.
That being said, this sort of thing happens pretty often.

In Oauth 1.0a and in WRAP, this attack is not possible. In both WRAP and in
Oauth 1.0a, the victim¹s browser is issued a verification code which somehow
must be passed back to the attacker in order for the attacker to access the
victim¹s private data. While the Web Server and Web Client flows both have
the verification_code to prevent the session fixation attack, the Device
Flow does not.

Is this a problem?

Allen

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

Re: [OAUTH-WG] Draft progress update

[Allen Tom]

The way we do this at Yahoo is that the developer must indicate what scopes
they want to access when registering for a client_identifier/secret.

Although we've done it this way for several years, we've gotten plenty of
feedback that client developers want the flexibility to specify the scopes
at user authorization time.

Allen


On 4/1/10 6:59 PM, "Peter Saint-Andre"  wrote:

> 
> 
> If that's true, then how does the Authorization Server know what scope
> is appropriate at the Protected Resource? Does inclusion of the scope
> parameter require a 1:1 mapping between AS and PR, or at least
> communication between AS and PR?
> 
> Peter

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

Re: [OAUTH-WG] Draft progress update

[Peter Saint-Andre]

On 4/1/10 4:22 PM, Justin Smith wrote:
>> I don't see why an opaque scope parameter would create any
>> problems for a library implementation. Working on such an
>> implementation right now and opaque scopes are perfectly fine.
> 
> I completely agree. In practice this hasn't caused a problem. We
> discussed the idea of forcing an absolute URI here and whether it had
> to be the actual resource URI. That doesn't work when the AS uses the
> same access policy for multiple resources. Opaque seems like a fine
> proposal to me.
> 
>>> Comment 3: This isn't the case when the client is presenting a
>>> token issued by another server. I suggest a change to something
>>> like the following: "When requesting access from the
>>> authorization server, the client identifies itself using client
>>> credentials known to the authorization server."
>> 
>> What token? The authorization endpoint isn't an OAuth-protected
>> resource.
> 
> In the case where you present a SAML (or other format) assertion, it
> is a kind of a protected resource - the resource is an access token.
> 
>>> This isn't the old testament. No need to look for hidden meaning.
>>> The spec is about getting access to protected resources,
>>> generally dealing with *a* protected resource. How resources are
>>> segmented is beyond the scope. I think it is more useful to talk
>>> about it using simpler assumptions - it doesn't prevent the more
>>> complex use cases.
> 
>> I think this ties in with the scope parameter. When requesting
>> authorization, if a client can also pass a scope parameter, then
>> access is granted only to the resources that accept that scope and
>> not to all resources controlled by this Authorization Server.
> 
> This is only a minor wording comment, but I think the idea is
> significant. The assumption that there is a 1:1 mapping between an AS
> and a PR seems out of place for the spec. It's easy to imagine that a
> single AS controls access to many resources (photos, friends, address
> books, etc.) - this is in fact what happens today.

If that's true, then how does the Authorization Server know what scope
is appropriate at the Protected Resource? Does inclusion of the scope
parameter require a 1:1 mapping between AS and PR, or at least
communication between AS and PR?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] User Interface specs?

[Allen Tom]

Websites using OpenID/OAuth/Facebook Connect/Twitter Connect often open a
popup window to the user¹s Identity Provider for user to complete the
AuthZ/AuthN flow rather than taking the user away from the referring site
via a full page redirect.

In the case where a popup window is used, it¹s a very good idea to require
that that the browser¹s address bar is displayed, and that an independent
browser window is used, rather than an inline iframe. These requirements are
needed to help prevent the user from being phished in the case where the
user has to enter their password, and to ensure that the user¹s consent was
not forged via a clickjacking attack.

I believe that the Web Server Flow and the Web Client Flow will often take
place within a popup window, so it would make sense to put into the core
spec that popups should be independent browser windows with the address bar
clearly displayed. 

Another missing feature in the core spec is support for multiple languages.
Given that many Service Providers have a global userbase, client
applications will want to have a way to specify the language to be used on
the auth screen. While the User Agent¹s Accept-Language: HTTP header, as
well as the user¹s IP address could be used as language hints, in practice
clients will want the ability to specify the language.

Is there consensus to get Popup Window requirements and language support
into the OAuth2 core spec?

Allen

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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Brian Eaton]

On Thu, Apr 1, 2010 at 5:10 PM, Eran Hammer-Lahav  wrote:
> Are they profiling a half page spec?

The spec is 66 pages long.  But the widely used pieces are quite a bit
shorter. =)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft progress update

[Allen Tom]

+1 on removing the recommendation to keep the tokens shorter than 255 chars.

While it's certainly a good idea to keep tokens reasonably compact, the same
way it's a great idea to keep URLs and Cookies short, the statement in the
spec doesn't really do much.

In practice, the tokens/urls/parameters need to be short enough such that
the resulting URLs are less than 2KB (to support useragents and proxy
servers that truncate long URLs) and that the HTTP Authorization header is
less than the maximum allowed size (?? chars).

I do acknowledge that it's ideal to specify a size limit on tokens - it
makes life easier for implementers so that they'll be able to size their
databases, and bandwidth/CPU constrained devices (aka mobile) will also
benefit from having compact tokens.

Allen


On 4/1/10 11:37 AM, "Marius Scurtescu"  wrote:

> +1 on all comments, except for some question on 6...
> 
> 
> On Thu, Apr 1, 2010 at 11:06 AM, Justin Smith  wrote:
>> Eran,
>> 
>> Good progress. A few comments below:
>> 
>> Sec. 2.2.  Flow Parameters:
>> Comment 1: The recommendation to keep access tokens less than 255 chars seems
>> bizarre. I'd like to remove it entirely. Previous threads have discussed
>> this.
>

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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Eran Hammer-Lahav]

Are they profiling a half page spec?

EHL

On Apr 1, 2010, at 19:53, "Brian Eaton"  wrote:

> On Thu, Apr 1, 2010 at 3:38 PM, Chuck Mortimore
>  wrote:
>> Flexibility.   If we lock Oauth2 down to one specific specific  
>> Assertion, it
>> becomes unusable for other assertion formats.   Those assertion  
>> formats will
>> evolve anyways.
>
> Yep.  The SAML Web SSO profiles are living proof that something can be
> underspecified (e.g. assertion details are vague), yet still widely
> implemented and very useful.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What are the OAuth design principles?

[Peter Saint-Andre]

On 3/24/10 11:32 AM, Leif Johansson wrote:
> On 03/23/2010 12:00 AM, Eve Maler wrote:
>> Since the discussion in the "OAuth after-party" seemed to warrant
>> bringing it up, I mentioned the UMA design principles/requirements
>> document.  You can find it here:
>>
>> http://kantarainitiative.org/confluence/display/uma/UMA+Requirements
>>
>> The discussion is around "Why can't Kerberos just be used for your use
>> cases?"  The UMA principles might be able to inform how the OAuth WG
>> makes its case for why Kerberos doesn't suffice.  (If we discover it
>> does, hey, our work here is done. :-)
> 
> There are two threads here
> 
> - why Kerberos _as such_ does or does not work for the use-cases
> - what experiences from 3rd party schemes such as Kerberos or STS are
> valuable for OAuth.
> 
> Being long-time Kerberos-fanboy I still say that one of those threads
> are interesting and the other isn't.
> 
> I think its much more valuable to talk about how to distill experience
> from Kerberos (etc) which are applicable to the design of OAuth.

Agreed. Do you know if anyone has written up the design principles
behind (or lessons learned) from Kerberos and STS? If not, we'll need to
start prodding people into sharing their wisdom...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Brian Eaton]

On Thu, Apr 1, 2010 at 3:38 PM, Chuck Mortimore
 wrote:
> Flexibility.   If we lock Oauth2 down to one specific specific Assertion, it
> becomes unusable for other assertion formats.   Those assertion formats will
> evolve anyways.

Yep.  The SAML Web SSO profiles are living proof that something can be
underspecified (e.g. assertion details are vague), yet still widely
implemented and very useful.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Chuck Mortimore]

Flexibility.   If we lock Oauth2 down to one specific specific Assertion, it 
becomes unusable for other assertion formats.   Those assertion formats will 
evolve anyways.Looked at somewhat differently, if there is only 1 assertion 
format supported by the spec, then what is the point of the assertion_format 
attribute?

So I'm clear, I'm 100% in favor of having a canonical assertion format for SAML 
with OAuth2, I really only intend to initially support 1 format, and I'm happy 
to take a stab at defining it.

I do think it's worthwhile for the spec to be open to other formats/assertions 
to be profiled over this same message exchange pattern.

One approach might be to change "2.6.2.  SAML Assertion Flow"  into  "2.7.  
Assertion Flow" and then have a base "Assertion Flow" followed by a  "SAML 
Assertion flow"  that builds on the base by defining explicit values for 
assertion_format and assertion.   Essentially have a core protocol + 1 single 
SAML profile of that protocol in the spec.

-cmort

On 4/1/10 3:16 PM, "Eran Hammer-Lahav"  wrote:

What is the value of an under specified flow? Especially one as short and 
simple as this one?

My point is that if the flow requires further profiling to be useful, the whole 
thing does belong in the core spec. It is short enough to be cut and paste into 
another spec repeatedly for each well specified assertion flow.

EHL

On Apr 1, 2010, at 16:34, "Chuck Mortimore"  wrote:

As you've pointed out, the current text is in somewhat of a grey area.   It's 
either over specified ( remove any reference to SAML ) or underspecified ( be 
very explicit about exactly what is expected )

I'd advocate that the core spec is left under-specified.   If we're 
prescriptive on the exact version and format of SAML, than the result will be 
other use-cases will simply force non-standard extensions.   It seems we do 
need to document exactly what what specific values of assertion_format 
requires, but the core spec should be open to multiple formats.

This would allow for flexibility with SAML, which has multiple versions, 
formats, and confirmation methods, but also allow for this message exchange 
patterns with completely different assertion types.   It will somewhat future 
proof the core spec.

Note that I'd be happy to work on the documentation of a specific format and 
contribute that to the group.

-cmort


On 4/1/10 12:24 PM, "Eran Hammer-Lahav" mailto:e...@hueniverse.com> > wrote:

A generic assertion flow is too under-specified to be included. If a SAML2 
assertion flow isn't enough or useful, we should define what is and fully 
specify it. The current text is still incomplete as it doesn't address how the 
assertion should be encoded in the request.

EHL


On 4/1/10 11:21 AM, "Marius Scurtescu" mailto:mscurte...@google.com> > wrote:

Instead of "SAML Assertion Flow" maybe we should stick with the more
generic "Assertion Flow".

The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1" and "saml2"?

Marius



On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav mailto:e...@hueniverse.com> > wrote:
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
>
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protected
> resources), and made most of the parameter names shorter. I am not done so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth 
> 
> .txt
>
> Please feel free to comment on anything you like or dislike. I will publish
> the whole thing as an I-D once it is feature complete for the WG to discuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> ___
> 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

Re: [OAUTH-WG] Draft progress update

[Justin Smith]

> I don't see why an opaque scope parameter would create any problems
> for a library implementation. Working on such an implementation right
> now and opaque scopes are perfectly fine.

I completely agree. In practice this hasn't caused a problem. We discussed the 
idea of forcing an absolute URI here and whether it had to be the actual 
resource URI. That doesn't work when the AS uses the same access policy for 
multiple resources. Opaque seems like a fine proposal to me.

>> Comment 3: This isn't the case when the client is presenting a token issued 
>> by
>> another server. I suggest a change to something like the following: "When
>> requesting access from the authorization server, the client identifies itself
>> using client credentials known to the authorization server."
>
> What token? The authorization endpoint isn't an OAuth-protected resource.

In the case where you present a SAML (or other format) assertion, it is a kind 
of a protected resource - the resource is an access token.

>> This isn't the old testament. No need to look for hidden meaning. The spec
>> is about getting access to protected resources, generally dealing with *a*
>> protected resource. How resources are segmented is beyond the scope. I think
>> it is more useful to talk about it using simpler assumptions - it doesn't
>> prevent the more complex use cases.

> I think this ties in with the scope parameter. When requesting authorization,
> if a client can also pass a scope parameter, then access is granted only
> to the resources that accept that scope and not to all resources controlled
> by this Authorization Server.

This is only a minor wording comment, but I think the idea is significant. The 
assumption that there is a 1:1 mapping between an AS and a PR seems out of 
place for the spec. It's easy to imagine that a single AS controls access to 
many resources (photos, friends, address books, etc.) - this is in fact what 
happens today. 


--justin

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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Eran Hammer-Lahav]

What is the value of an under specified flow? Especially one as short and 
simple as this one?

My point is that if the flow requires further profiling to be useful, the whole 
thing does belong in the core spec. It is short enough to be cut and paste into 
another spec repeatedly for each well specified assertion flow.

EHL

On Apr 1, 2010, at 16:34, "Chuck Mortimore" 
mailto:cmortim...@salesforce.com>> wrote:

As you’ve pointed out, the current text is in somewhat of a grey area.   It’s 
either over specified ( remove any reference to SAML ) or underspecified ( be 
very explicit about exactly what is expected )

I’d advocate that the core spec is left under-specified.   If we’re 
prescriptive on the exact version and format of SAML, than the result will be 
other use-cases will simply force non-standard extensions.   It seems we do 
need to document exactly what what specific values of assertion_format 
requires, but the core spec should be open to multiple formats.

This would allow for flexibility with SAML, which has multiple versions, 
formats, and confirmation methods, but also allow for this message exchange 
patterns with completely different assertion types.   It will somewhat future 
proof the core spec.

Note that I’d be happy to work on the documentation of a specific format and 
contribute that to the group.

-cmort


On 4/1/10 12:24 PM, "Eran Hammer-Lahav" 
> wrote:

A generic assertion flow is too under-specified to be included. If a SAML2 
assertion flow isn’t enough or useful, we should define what is and fully 
specify it. The current text is still incomplete as it doesn’t address how the 
assertion should be encoded in the request.

EHL


On 4/1/10 11:21 AM, "Marius Scurtescu" 
> 
wrote:

Instead of "SAML Assertion Flow" maybe we should stick with the more
generic "Assertion Flow".

The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1" and "saml2"?

Marius



On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav 
> wrote:
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
>
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protected
> resources), and made most of the parameter names shorter. I am not done so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> 
>  http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
> .txt
>
> Please feel free to comment on anything you like or dislike. I will publish
> the whole thing as an I-D once it is feature complete for the WG to discuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> ___
> 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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Chuck Mortimore]

As you've pointed out, the current text is in somewhat of a grey area.   It's 
either over specified ( remove any reference to SAML ) or underspecified ( be 
very explicit about exactly what is expected )

I'd advocate that the core spec is left under-specified.   If we're 
prescriptive on the exact version and format of SAML, than the result will be 
other use-cases will simply force non-standard extensions.   It seems we do 
need to document exactly what what specific values of assertion_format 
requires, but the core spec should be open to multiple formats.

This would allow for flexibility with SAML, which has multiple versions, 
formats, and confirmation methods, but also allow for this message exchange 
patterns with completely different assertion types.   It will somewhat future 
proof the core spec.

Note that I'd be happy to work on the documentation of a specific format and 
contribute that to the group.

-cmort


On 4/1/10 12:24 PM, "Eran Hammer-Lahav"  wrote:

A generic assertion flow is too under-specified to be included. If a SAML2 
assertion flow isn't enough or useful, we should define what is and fully 
specify it. The current text is still incomplete as it doesn't address how the 
assertion should be encoded in the request.

EHL


On 4/1/10 11:21 AM, "Marius Scurtescu"  wrote:

Instead of "SAML Assertion Flow" maybe we should stick with the more
generic "Assertion Flow".

The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1" and "saml2"?

Marius



On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav  wrote:
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
>
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protected
> resources), and made most of the parameter names shorter. I am not done so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
> .txt
>
> Please feel free to comment on anything you like or dislike. I will publish
> the whole thing as an I-D once it is feature complete for the WG to discuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> ___
> 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

Re: [OAUTH-WG] Draft progress update

[Marius Scurtescu]

On Thu, Apr 1, 2010 at 12:23 PM, Eran Hammer-Lahav  wrote:
> On 4/1/10 11:06 AM, "Justin Smith"  wrote:
>> General comment on the flows:
>> Comment 2: The scope parameter (from WRAP) is missing from all of the flows.
>> How does the client indicate which protected resource it intends to access? 
>> In
>> WRAP this was an optional parameter, but it seems important when a single AS
>> controls access to many resources.
>
> I removed it (for now) because it was (way way) under specified. The only
> reason for a spec is interop. This parameter hurts interop because it forces
> library to implement something they cannot understand, or understand based
> on one deployment.
>
> This debate has been going on for a long time and solving it by simply
> adding a placeholder for scope without *any* structure or definition is not
> how well designed protocols are written.
>
> I have always maintained that OAuth needs a basic facility to negotiate
> scope. It can be as simple as an opaque string identifying a set of
> resources (e.g. HTTP auth realms), a JSON string of key/value pairs, etc.
> But as present in WRAP and imported by David it is utterly useless (it is
> and under-specified SHOULD - I am not really sure what it is to be used
> for).
>
> Write a proposal and we can add it back.

Except for trivial cases, the client needs to have custom code to access and
process the protected resources. Scopes have meaning only for these
resources and while obtaining an access token I think the scope can be
treated as an opaque string.

There is another issue with removing the scope parameter. In most cases
a scope parameter will be needed in practice, if the spec does not specify
one then an additional non-standard parameter must be used. But you also
dropped the additional parameters.

I don't see why an opaque scope parameter would create any problems
for a library implementation. Working on such an implementation right
now and opaque scopes are perfectly fine.


>> Sec. 2.3.  Client Credentials: "When requesting access from the authorization
>> server, the client identifies itself using its authorization-server-issued
>> client credentials."
>> Comment 3: This isn't the case when the client is presenting a token issued 
>> by
>> another server. I suggest a change to something like the following: "When
>> requesting access from the authorization server, the client identifies itself
>> using client credentials known to the authorization server."
>
> What token? The authorization endpoint isn't an OAuth-protected resource.
>
>> Sec. 2.4.  User Delegation Flows: "Instead, the end user authenticates
>> directly with the authorization server, and grants client access to its
>> protected resources."
>> Comment 4: This is a minor nit, but the AS may not grant access to all of the
>> PRs it controls access to. I suggest a change to something like the 
>> following:
>> "... and grants client access to the requested protected resources."
>
> This isn't the old testament. No need to look for hidden meaning. The spec
> is about getting access to protected resources, generally dealing with *a*
> protected resource. How resources are segmented is beyond the scope. I think
> it is more useful to talk about it using simpler assumptions - it doesn't
> prevent the more complex use cases.

I think this ties in with the scope parameter. When requesting authorization,
if a client can also pass a scope parameter, then access is granted only
to the resources that accept that scope and not to all resources controlled
by this Authorization Server.


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

Re: [OAUTH-WG] Draft progress update

[Marius Scurtescu]

On Thu, Apr 1, 2010 at 12:31 PM, Eran Hammer-Lahav  wrote:
>
> On 4/1/10 11:37 AM, "Marius Scurtescu"  wrote:
>
>> SAML assertions contain the expiry inside, the OAuth "expires"
>> parameter would be redundant, maybe this is way it is optional?
>
> The token expiration doesn't have to be the same as the assertion.

Yep, sorry, I got mixed up.


>> But, do we want to make this parameter required in general? Why not
>> leave it optional for all flows? What if an Authorization Server
>> implements some other mechanism to expire them (number of uses for
>> example) and a fixed expiry time does not make sense?
>
> The expiration parameter should be optional everywhere. If it is not, its
> because I didn't get to it (or messed up).

Sounds great.


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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Marius Scurtescu]

On Thu, Apr 1, 2010 at 12:24 PM, Eran Hammer-Lahav  wrote:
> A generic assertion flow is too under-specified to be included.

Can you please give some more details, why is that?

For any assertion flow to work the client and the authorization server
must trust
each other, leaving the assertion format details up to them seems reasonable
to me.


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

Re: [OAUTH-WG] Draft progress update

[Eran Hammer-Lahav]

On 4/1/10 11:37 AM, "Marius Scurtescu"  wrote:

> SAML assertions contain the expiry inside, the OAuth "expires"
> parameter would be redundant, maybe this is way it is optional?

The token expiration doesn't have to be the same as the assertion.

> But, do we want to make this parameter required in general? Why not
> leave it optional for all flows? What if an Authorization Server
> implements some other mechanism to expire them (number of uses for
> example) and a fixed expiry time does not make sense?

The expiration parameter should be optional everywhere. If it is not, its
because I didn't get to it (or messed up).


EHL


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

Re: [OAUTH-WG] Draft progress update

[Eran Hammer-Lahav]

On 4/1/10 11:29 AM, "Marius Scurtescu"  wrote:

> Also, not only the Authorization Server URLs can receive OAuth
> parameters in the query,
> the same applies to the client callback URL, and that one definitely
> can have random
> parameters.

We are discussing just the authorization endpoint, but if you look at the
current draft, it proposes we limit client customization of the callbacks to
the state parameter (i.e. No query allowed). This is a new. My take is that
either we use the state parameter or we use custom query parameters (with
prefix) but not both. I like the state parameter better (stronger interop
and easier to pre-register URIs).

EHL

> 
> Marius
> ___
> 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

Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

[Eran Hammer-Lahav]

A generic assertion flow is too under-specified to be included. If a SAML2 
assertion flow isn't enough or useful, we should define what is and fully 
specify it. The current text is still incomplete as it doesn't address how the 
assertion should be encoded in the request.

EHL


On 4/1/10 11:21 AM, "Marius Scurtescu"  wrote:

Instead of "SAML Assertion Flow" maybe we should stick with the more
generic "Assertion Flow".

The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1" and "saml2"?

Marius



On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav  wrote:
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
>
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protected
> resources), and made most of the parameter names shorter. I am not done so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
> .txt
>
> Please feel free to comment on anything you like or dislike. I will publish
> the whole thing as an I-D once it is feature complete for the WG to discuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> ___
> 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

Re: [OAUTH-WG] Draft progress update

[Eran Hammer-Lahav]

Hi Justin,


On 4/1/10 11:06 AM, "Justin Smith"  wrote:

> Sec. 2.2.  Flow Parameters:
> Comment 1: The recommendation to keep access tokens less than 255 chars seems
> bizarre. I'd like to remove it entirely. Previous threads have discussed this.

It's marked as an open issue. I personally don't care much either way but
can see the reasons behind those for and against a (short) hard limit.
Experience has shown this is a problem as most libraries assume a certain
size will work just fine and then blow up.

Last time it was debated here it didn't end with a consensus call so feel
free to ask the chairs for one or continue debating it.

> General comment on the flows:
> Comment 2: The scope parameter (from WRAP) is missing from all of the flows.
> How does the client indicate which protected resource it intends to access? In
> WRAP this was an optional parameter, but it seems important when a single AS
> controls access to many resources.

I removed it (for now) because it was (way way) under specified. The only
reason for a spec is interop. This parameter hurts interop because it forces
library to implement something they cannot understand, or understand based
on one deployment.

This debate has been going on for a long time and solving it by simply
adding a placeholder for scope without *any* structure or definition is not
how well designed protocols are written.

I have always maintained that OAuth needs a basic facility to negotiate
scope. It can be as simple as an opaque string identifying a set of
resources (e.g. HTTP auth realms), a JSON string of key/value pairs, etc.
But as present in WRAP and imported by David it is utterly useless (it is
and under-specified SHOULD - I am not really sure what it is to be used
for).

Write a proposal and we can add it back.

> Sec. 2.3.  Client Credentials: "When requesting access from the authorization
> server, the client identifies itself using its authorization-server-issued
> client credentials."
> Comment 3: This isn't the case when the client is presenting a token issued by
> another server. I suggest a change to something like the following: "When
> requesting access from the authorization server, the client identifies itself
> using client credentials known to the authorization server."

What token? The authorization endpoint isn't an OAuth-protected resource.
 
> Sec. 2.4.  User Delegation Flows: "Instead, the end user authenticates
> directly with the authorization server, and grants client access to its
> protected resources."
> Comment 4: This is a minor nit, but the AS may not grant access to all of the
> PRs it controls access to. I suggest a change to something like the following:
> "... and grants client access to the requested protected resources."

This isn't the old testament. No need to look for hidden meaning. The spec
is about getting access to protected resources, generally dealing with *a*
protected resource. How resources are segmented is beyond the scope. I think
it is more useful to talk about it using simpler assumptions - it doesn't
prevent the more complex use cases.

> Sec. 2.6.2.  SAML Assertion Flow: "Since requests to the authorization
> endpoint result in the transmission of plain text credentials in the HTTP
> request and response, ..."
> Comment 5: In the case of the SAML assertion flow (or an assertion of another
> format), it isn't necessarily the case that the assertion is plain text. You
> might want to change it to: "...authorization endpoint may result in the...".
> Comment 6: why is expiration optional in the response? It seems like it should
> be mandatory (as it is in the other flows).

I didn't really get to that part yet in my full rewrite - just imported it
with small changes. The new spec has a simple authorization endpoint and it
requires SSL/TLS (or other secure channels). The same applies to this flow.
The assertion might not be plain text but the resulting token is.

> Sec. 2.6.1 Client Credentials Flow:
> Comment 7: Why require a refresh token? Assumedly the client has to keep the
> client_id and client_secret, so why not just present them to the AS again for
> an access token? Brian/Marius/Dick brought this up earlier - you just might
> not have gotten there yet.

Yep. On my list.

Thanks!

EHL

> 
> --justin
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
> Hammer-Lahav
> Sent: Wednesday, March 31, 2010 6:22 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Draft progress update
> 
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
> 
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protec

Re: [OAUTH-WG] Draft progress update

[Marius Scurtescu]

+1 on all comments, except for some question on 6...


On Thu, Apr 1, 2010 at 11:06 AM, Justin Smith  wrote:
> Eran,
>
> Good progress. A few comments below:
>
> Sec. 2.2.  Flow Parameters:
> Comment 1: The recommendation to keep access tokens less than 255 chars seems 
> bizarre. I'd like to remove it entirely. Previous threads have discussed this.
>
> General comment on the flows:
> Comment 2: The scope parameter (from WRAP) is missing from all of the flows. 
> How does the client indicate which protected resource it intends to access? 
> In WRAP this was an optional parameter, but it seems important when a single 
> AS controls access to many resources.
>
> Sec. 2.3.  Client Credentials: "When requesting access from the authorization 
> server, the client identifies itself using its authorization-server-issued 
> client credentials."
> Comment 3: This isn't the case when the client is presenting a token issued 
> by another server. I suggest a change to something like the following: "When 
> requesting access from the authorization server, the client identifies itself 
> using client credentials known to the authorization server."
>
> Sec. 2.4.  User Delegation Flows: "Instead, the end user authenticates 
> directly with the authorization server, and grants client access to its 
> protected resources."
> Comment 4: This is a minor nit, but the AS may not grant access to all of the 
> PRs it controls access to. I suggest a change to something like the 
> following: "... and grants client access to the requested protected 
> resources."
>
> Sec. 2.6.2.  SAML Assertion Flow: "Since requests to the authorization 
> endpoint result in the transmission of plain text credentials in the HTTP 
> request and response, ..."
> Comment 5: In the case of the SAML assertion flow (or an assertion of another 
> format), it isn't necessarily the case that the assertion is plain text. You 
> might want to change it to: "...authorization endpoint may result in the...".
> Comment 6: why is expiration optional in the response? It seems like it 
> should be mandatory (as it is in the other flows).

SAML assertions contain the expiry inside, the OAuth "expires"
parameter would be redundant, maybe this is way it is optional?

But, do we want to make this parameter required in general? Why not
leave it optional for all flows? What if an Authorization Server
implements some other mechanism to expire them (number of uses for
example) and a fixed expiry time does not make sense?


> Sec. 2.6.1 Client Credentials Flow:
> Comment 7: Why require a refresh token? Assumedly the client has to keep the 
> client_id and client_secret, so why not just present them to the AS again for 
> an access token? Brian/Marius/Dick brought this up earlier - you just might 
> not have gotten there yet.
>
>
> --justin
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Eran Hammer-Lahav
> Sent: Wednesday, March 31, 2010 6:22 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Draft progress update
>
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
>
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protected
> resources), and made most of the parameter names shorter. I am not done so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
> .txt
>
> Please feel free to comment on anything you like or dislike. I will publish
> the whole thing as an I-D once it is feature complete for the WG to discuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> ___
> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft progress update

[Marius Scurtescu]

On Thu, Apr 1, 2010 at 11:22 AM, David Recordon  wrote:
> On Thu, Apr 1, 2010 at 9:51 AM, Marius Scurtescu  
> wrote:
>> Hi Luke,
>> On Wed, Mar 31, 2010 at 10:28 PM, Luke Shepard  wrote:
>>> At first, I had the same first reaction as Marius, but after reading this
>>> thread, I agree with Eran. Two observations:
>>> 1/ OAuth endpoints are usually already namespaced as "oauth" - if there are
>>> other endpoints that accept custom parameters, they can be defined
>>> elsewhere. For example:
>>> https://www.google.com/accounts/OAuthAuthorizeToken
>>> https://api.login.yahoo.com/oauth/v2/request_auth
>>> http://twitter.com/oauth/authorize
>>
>> The fact that the endpoint URL has "oauth" in it will not prevent any
>> collisions.
>
> I think Luke's point is that OAuth deployment today is not being done
> by complex frameworks which add their own parameters, rather the
> majority of deployers make custom endpoints specifically for OAuth.  I
> also don't see how the Authorization Server's web framework would add
> random parameters given that an unknown client is making the HTTP
> request to it.

Not random, they can be query parameters that are part of the
published URL, something like:
http://example.com/auth?mode=oauth

Also, not only the Authorization Server URLs can receive OAuth
parameters in the query,
the same applies to the client callback URL, and that one definitely
can have random
parameters.


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

Re: [OAUTH-WG] Draft progress update

[David Recordon]

On Thu, Apr 1, 2010 at 9:51 AM, Marius Scurtescu  wrote:
> Hi Luke,
> On Wed, Mar 31, 2010 at 10:28 PM, Luke Shepard  wrote:
>> At first, I had the same first reaction as Marius, but after reading this
>> thread, I agree with Eran. Two observations:
>> 1/ OAuth endpoints are usually already namespaced as "oauth" - if there are
>> other endpoints that accept custom parameters, they can be defined
>> elsewhere. For example:
>> https://www.google.com/accounts/OAuthAuthorizeToken
>> https://api.login.yahoo.com/oauth/v2/request_auth
>> http://twitter.com/oauth/authorize
>
> The fact that the endpoint URL has "oauth" in it will not prevent any
> collisions.

I think Luke's point is that OAuth deployment today is not being done
by complex frameworks which add their own parameters, rather the
majority of deployers make custom endpoints specifically for OAuth.  I
also don't see how the Authorization Server's web framework would add
random parameters given that an unknown client is making the HTTP
request to it.


>> 2/ We should fight to keep URLs short and leave out redundant information
>> where possible. We should leave out redundant information where possible.
>> Here are two sample URLs. The first is 12% shorter than the second.
>> http://facebook.com/oauth/authorize?mode=web_callback_access_request&client_id=123456789&callback=http://facebook.com/oauth/callback
>> http://facebook.com/oauth/authorize?oauth_mode=web_callback_access_request&oauth_client_id=123456789&oauth_callback=http://facebook.com/oauth/callback
>
> Yes, shorter in general is better. In this case it is just a bit shorter, it 
> is
> exactly 18 chars shorter, regardless of the URL length. What is this buying
> us? End users don't have to type these URLs.
>
>
> Marius
> ___
> 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] SAML Assertion Flow (was: Draft progress update)

[Marius Scurtescu]

Instead of "SAML Assertion Flow" maybe we should stick with the more
generic "Assertion Flow".

The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1" and "saml2"?

Marius



On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav  wrote:
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
>
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protected
> resources), and made most of the parameter names shorter. I am not done so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
> .txt
>
> Please feel free to comment on anything you like or dislike. I will publish
> the whole thing as an I-D once it is feature complete for the WG to discuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> ___
> 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

Re: [OAUTH-WG] Draft progress update

[Justin Smith]

Eran,

Good progress. A few comments below:

Sec. 2.2.  Flow Parameters:
Comment 1: The recommendation to keep access tokens less than 255 chars seems 
bizarre. I'd like to remove it entirely. Previous threads have discussed this.

General comment on the flows:
Comment 2: The scope parameter (from WRAP) is missing from all of the flows. 
How does the client indicate which protected resource it intends to access? In 
WRAP this was an optional parameter, but it seems important when a single AS 
controls access to many resources.

Sec. 2.3.  Client Credentials: "When requesting access from the authorization 
server, the client identifies itself using its authorization-server-issued 
client credentials."
Comment 3: This isn't the case when the client is presenting a token issued by 
another server. I suggest a change to something like the following: "When 
requesting access from the authorization server, the client identifies itself 
using client credentials known to the authorization server."   

Sec. 2.4.  User Delegation Flows: "Instead, the end user authenticates directly 
with the authorization server, and grants client access to its protected 
resources."
Comment 4: This is a minor nit, but the AS may not grant access to all of the 
PRs it controls access to. I suggest a change to something like the following: 
"... and grants client access to the requested protected resources."

Sec. 2.6.2.  SAML Assertion Flow: "Since requests to the authorization endpoint 
result in the transmission of plain text credentials in the HTTP request and 
response, ..."
Comment 5: In the case of the SAML assertion flow (or an assertion of another 
format), it isn't necessarily the case that the assertion is plain text. You 
might want to change it to: "...authorization endpoint may result in the...". 
Comment 6: why is expiration optional in the response? It seems like it should 
be mandatory (as it is in the other flows).

Sec. 2.6.1 Client Credentials Flow:
Comment 7: Why require a refresh token? Assumedly the client has to keep the 
client_id and client_secret, so why not just present them to the AS again for 
an access token? Brian/Marius/Dick brought this up earlier - you just might not 
have gotten there yet.


--justin

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer-Lahav
Sent: Wednesday, March 31, 2010 6:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update

I'm making good progress working off David's draft and bringing text from
WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
it is largely in line with David's proposal and the majority of changes are
purely editorial.

The only significant change I have made (which is of course open to debate)
is renaming all the authorization flows parameters. I dropped the oauth_
prefix (no real need since these are purely OAuth endpoints, not protected
resources), and made most of the parameter names shorter. I am not done so
they are not consistent yet.

You can follow my progress (changes every few hours) at:

http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
.txt

Please feel free to comment on anything you like or dislike. I will publish
the whole thing as an I-D once it is feature complete for the WG to discuss
before we promote this to a WG draft.

I hope to be done with the initial draft by middle of next week (I'll be
flying most of Fri-Sat so no progress over the weekend).

EHL

___
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

Re: [OAUTH-WG] Draft progress update

[Marius Scurtescu]

Hi Luke,


On Wed, Mar 31, 2010 at 10:28 PM, Luke Shepard  wrote:
> At first, I had the same first reaction as Marius, but after reading this
> thread, I agree with Eran. Two observations:
> 1/ OAuth endpoints are usually already namespaced as "oauth" - if there are
> other endpoints that accept custom parameters, they can be defined
> elsewhere. For example:
> https://www.google.com/accounts/OAuthAuthorizeToken
> https://api.login.yahoo.com/oauth/v2/request_auth
> http://twitter.com/oauth/authorize

The fact that the endpoint URL has "oauth" in it will not prevent any
collisions.


> 2/ We should fight to keep URLs short and leave out redundant information
> where possible. We should leave out redundant information where possible.
> Here are two sample URLs. The first is 12% shorter than the second.
> http://facebook.com/oauth/authorize?mode=web_callback_access_request&client_id=123456789&callback=http://facebook.com/oauth/callback
> http://facebook.com/oauth/authorize?oauth_mode=web_callback_access_request&oauth_client_id=123456789&oauth_callback=http://facebook.com/oauth/callback

Yes, shorter in general is better. In this case it is just a bit shorter, it is
exactly 18 chars shorter, regardless of the URL length. What is this buying
us? End users don't have to type these URLs.


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

Re: [OAUTH-WG] Draft progress update

[Marius Scurtescu]

Hi Eran,


On Wed, Mar 31, 2010 at 9:17 PM, Eran Hammer-Lahav  wrote:
> Hey Marius,
>
> On 3/31/10 8:37 PM, "Marius Scurtescu"  wrote:
>
>> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav 
>> wrote:
>>> The only significant change I have made (which is of course open to debate)
>>> is renaming all the authorization flows parameters. I dropped the oauth_
>>> prefix (no real need since these are purely OAuth endpoints, not protected
>>> resources), and made most of the parameter names shorter. I am not done so
>>> they are not consistent yet.
>>
>> Having a common prefix for all parameters is quite important IMO. It
>> allows parties
>> to define and pass additional, non-standard, parameters.
>
> Non-standard parameter hurt interoperability. The question is whether the
> right approach is to add a prefix to the protocol parameters or to the
> extension parameters (such as x_), or none.

I agree that non-standard parameters are far from ideal, but they are used in
practice for various reasons.


> What prevents a custom parameter to collide with a standard extension not
> supported by the server or someone else's custom parameter? If we are
> serious about parameter collision (which I doubt given past sentiments on
> registries etc.), we should require all parameters to register unless they
> have some special custom prefix.

That's a different issue IMO. In general if you use non-standard stuff you
are on your own. We should try to protect the standard part and I think
a prefix helps.


> In other word, adding the oauth_ prefix to the core parameters doesn't
> really accomplish much, other than making requests longer. In the past,
> people wanted to define extension parameters starting with oauth_ and we
> didn't really reach consensus on whether to allow it or not. Then we played
> with xoauth_ for a while, then went back and just allowed oauth_ for
> extensions.
>
> If we keep the oauth_ prefix, do we also require a registry for extensions?
> Do we define another prefix? Do we create a registry for extension prefixes?
> This gets bad really fast.

I don't see how dropping the prefix solves any of these problems. I think it
just makes matters worse.


>> Also, quite
>> often parameters
>> are added to existing URLs, and a prefix helps prevent collisions.
>
> Extension parameters should never conflict with core parameter because we
> know all the core parameters before we write custom ones...
>
> This is only for the OAuth-specific endpoint (authorization endpoint), not
> the protected resource endpoint in which we will still use oauth_token (the
> only parameter added to protected resource requests).

Yes, this is only for OAuth endpoints, but all kinds of frameworks will be used
to implement them I can imagne that many of them will use their own parameters.

Also, many implementation will probably choose to pass state through
the callback
URL, as query parameters (even though there is a special OAuth
parameter for that).


> What do you think?

What are the reasons we would drop the prefix? So far the only one I heard was
shorter messages, but I am not convinced this is a real problem.


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

Re: [OAUTH-WG] Draft progress update

[Eran Hammer-Lahav]

This is a correct observation but I am not sure if it would be useful to change 
the definition. The current definition isn't wrong, just (sometimes) 
incomplete. An OAuth client is an HTTP client speaking OAuth, but for the 
purpose of obtaining a token using the callback flow, it also has to have HTTP 
server capabilities. I don't think that voids the current definition.

I'll tweak the wording specific to the callback flow.

EHL


On 4/1/10 8:14 AM, "Zachary Zeltsan"  wrote:

Eran,

The progress is good indeed.

I believe that the following comment on the draft applies also to some previous 
versions of OAuth specifications.

In my opinion, the description of step A of the Web Callback Flow implies that 
a client
is an HTTP server:
(A)  The web client initiates the flow by redirecting the end user's
user-agent to the authorization endpoint ...

(If it is the HTTP redirection, then the client has to be an HTTP server).

If an OAuth client has to be an HTTP server in order to participate in OAuth 
flow, then the draft's definition of client appears to be incomplete:

client
 An HTTP client capable of making authenticated requests for
 protected resources using the OAuth protocol

Should not the definition reflect the fact that client has to be also an HTTP 
server (which appears to be the case at least for the Web Callback Flow)?

Zachary

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer-Lahav
Sent: Wednesday, March 31, 2010 9:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update

I'm making good progress working off David's draft and bringing text from
WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
it is largely in line with David's proposal and the majority of changes are
purely editorial.

The only significant change I have made (which is of course open to debate)
is renaming all the authorization flows parameters. I dropped the oauth_
prefix (no real need since these are purely OAuth endpoints, not protected
resources), and made most of the parameter names shorter. I am not done so
they are not consistent yet.

You can follow my progress (changes every few hours) at:

http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
.txt

Please feel free to comment on anything you like or dislike. I will publish
the whole thing as an I-D once it is feature complete for the WG to discuss
before we promote this to a WG draft.

I hope to be done with the initial draft by middle of next week (I'll be
flying most of Fri-Sat so no progress over the weekend).

EHL

___
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

Re: [OAUTH-WG] Draft progress update

[Zeltsan, Zachary (Zachary)]

Eran,



The progress is good indeed.



I believe that the following comment on the draft applies also to some previous 
versions of OAuth specifications.



In my opinion, the description of step A of the Web Callback Flow implies that 
a client

is an HTTP server:

(A)  The web client initiates the flow by redirecting the end user's

user-agent to the authorization endpoint ...



(If it is the HTTP redirection, then the client has to be an HTTP server).



If an OAuth client has to be an HTTP server in order to participate in OAuth 
flow, then the draft's definition of client appears to be incomplete:



client

 An HTTP client capable of making authenticated requests for

 protected resources using the OAuth protocol



Should not the definition reflect the fact that client has to be also an HTTP 
server (which appears to be the case at least for the Web Callback Flow)?



Zachary



-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer-Lahav
Sent: Wednesday, March 31, 2010 9:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Draft progress update



I'm making good progress working off David's draft and bringing text from

WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far

it is largely in line with David's proposal and the majority of changes are

purely editorial.



The only significant change I have made (which is of course open to debate)

is renaming all the authorization flows parameters. I dropped the oauth_

prefix (no real need since these are purely OAuth endpoints, not protected

resources), and made most of the parameter names shorter. I am not done so

they are not consistent yet.



You can follow my progress (changes every few hours) at:



http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth

.txt



Please feel free to comment on anything you like or dislike. I will publish

the whole thing as an I-D once it is feature complete for the WG to discuss

before we promote this to a WG draft.



I hope to be done with the initial draft by middle of next week (I'll be

flying most of Fri-Sat so no progress over the weekend).



EHL



___

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