[OAUTH-WG] Comments on Web Callback & Client Flow

[Evan Gilbert]

A few comments on the Web Server and Web Client flow from the draft
2.0 spec
.

Evan



2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
In both flows, the authorization server should be able redirect back to the
callback URI without interacting directly with the resource owner if access
has already been approved.  This is not ruled out in the current language
but it could be made cleaner.

Suggested rewording - change

"After receiving an authorization decision from the resource owner, the
server redirects the resource owner to the callback URI."

  to

"If the client is already approved or denied for access to the protected
resource, the authorization service MAY redirect the resource owner to the
callback URI immediately. If not, the authorization service SHOULD ask the
resource owner for an authorization decision and after receiving the
decision redirect the resource owner to the callback URI."



2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
We should have an OPTIONAL username parameter:
username
  The resource owner's username. The authorization server MUST only send
back refresh tokens or access tokens for this user.

This is useful for clients where a user is already logged into a 3rd party
web site with a specific account, and the client wants the authorization to
match the specific user.



2.4.2 Web Client Flow
Sending an access token as a query parameter is dangerous from a security
perspective - these tokens are leaked via referrers and server logs. In
previous WRAP discussions, it was felt that we should have a strong
recommendation to use the URL fragment.

Suggested wording:
Client SHOULD send a callback URI with a query fragment, and authorization
server MAY reject callback URLs without a fragment for security reasons.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft progress update

[Leif Johansson]

On 04/02/2010 06:07 AM, 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".



Here is a bit of Kerberos-lore: it is sometimes important to
protect your error messages too!

When you pass critical parameters ("you need this scope for
access"), the error message suddenly becomes something
you may have to protect.

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

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

[Leif Johansson]

On 04/02/2010 01:57 AM, Peter Saint-Andre wrote:

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


Thomas, does the mitkc has something written on the subject of Kerberos 
from 10k feet that might be useful in this context? I'm cc:ing lha who

also has tons of implementation experience.


Cheers Leif



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

Re: [OAUTH-WG] Renaming expires to expires_in?

[Richard Barnes]

Ok, maybe something like "lifetime"?


On Apr 5, 2010, at 12:46 PM, Paul Lindner wrote:


+1

This would more closely match the nomenclature used by the oauth  
session extension.



On Mon, Apr 5, 2010 at 9:09 AM, David Recordon > wrote:
As one of our engineers was implementing a client, they got confused  
about what was being returned by the expires parameter. Anyone  
object to renaming it to expires_in so that it's clear that it isn't  
an absolute timestamp?


Thanks,
--David
___
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] Renaming expires to expires_in?

[Paul Lindner]

+1

This would more closely match the nomenclature used by the oauth session
extension
.


On Mon, Apr 5, 2010 at 9:09 AM, David Recordon
wrote:

> As one of our engineers was implementing a client, they got confused about
> what was being returned by the expires parameter. Anyone object to renaming
> it to expires_in so that it's clear that it isn't an absolute timestamp?
>
> Thanks,
> --David
> ___
> 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] Renaming expires to expires_in?

[David Recordon]

As one of our engineers was implementing a client, they got confused about what 
was being returned by the expires parameter. Anyone object to renaming it to 
expires_in so that it's clear that it isn't an absolute timestamp?

Thanks,
--David
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth