Subject: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 10 May 2010 00:01:48 +0200

I have put together some comments/suggestions regarding the current draft.

3.2.1.  Response Format

The authorization server MUST include the HTTP "Cache-Control"
    response header field with a value of "no-store" in any response
    containing tokens, secrets, or other sensitive information.

Would'nt it make sense to require "no-cache", too?

3.2.1.1.  Access Token Response
    expires_in
          OPTIONAL.  The duration in seconds of the access token
          lifetime.

    refresh_token
          OPTIONAL.  The refresh token used to obtain new access tokens
          using the same end-user access grant as described in Section 6.

What is the exact meaning/idea of OPTIONAL response parameters?
Who actually decides to use them? The client or the authorization server 
or both?
Is it optional to implement this feature or is it envisioned the server 
dynamically decides to use those parameters based on its policy?

expires_in

Why is there information passed back about the access tokens duration 
but not about the refresh tokens duration?

3.2.1.2.  Error Response

  If the token request is invalid or unauthorized, the authorization
    server constructs a JSON-formatted response which includes the common
    parameters set as well as additional flow-specific parameters.  The
    formatted parameters are sent to the client in the entity body of the
    HTTP response with a 400 status code (Bad Request).

To use status code 400 for all kinds of errors is very generic from my 
point of view. How shall the client implement a
dedicated error handling if it cannot distinguish different errors. I 
would suggest either to define error codes (not only
messages) in the spec or to use appropriate HTTP status codes for 
different error conditions, e.g. 401 for unauthorized calls.

3.4.  Client Credentials

The client credentials include a client identifier and
    an OPTIONAL symmetric shared secret.

What is meant by "symmetric shared secret"? I'm familiar with the term 
"symmetric" in the context of cryptographical algorithms only. I think 
"shared secret" is sufficient.

3.5.  User-Agent Flow

These clients
    cannot keep client secrets confidential and the authentication of the
    client is based on the user-agent's same-origin policy.

Does this still hold in the context of "HTTP Origin Headers" 
(http://www.petefreitag.com/item/702.cfm)?

BTW: Will Brian's security considerations document be updated to be in 
sync with the draft?

3.5.1.  Client Requests Authorization

If the client has previously registered a redirection URI with the
    authorization server, the authorization server MUST verify that the
    redirection URI received matches the registered URI associated with
    the client identifier.

Does this mean equality? Or just the same base string?

3.5.1.1.  End-user Grants Authorization

I would suggest to use JSON encoding here, since the URI fragment is 
handled by a client more or less like a response result.

3.6.1.1.  End-user Grants Authorization

Why not call the "code" Parameter "verification_code"? It's called 
verification code in the text.

3.6.2.  Client Requests Access Token

client_secret
          REQUIRED if the client identifier has a matching secret.  The
          client secret as described in Section 3.4.

1) I'm having trouble to understand the meaning of  "if the client 
identifier has a matching secret". Is the
assumption underneath that authorization servers require this secrets 
from all clients they have issued a secret to?
What about client w/o a secret? Are they also allowed to use this flow? 
Or is there envisioned a dependency
between the client type, clients credentials and the flows a particular 
client is authorized to use?

I would have expected a clear policy which flows require authentication 
and which not.

2) I would suggest to replace the request parameter by an Authorization 
header. First of all because that's the
way credential transmission is handled in HTTP. Moreover, it better fits 
with error handling. If the secret
is missing or wrong, the authorization server can answer with status 
code 401 and a WWW-Authenticate header(s)
specifiying mechanism and realms to be used by the client in order to 
authenticate to the server.

In the long run it gives deployments more freedom to use other 
mechanisms than sending shared secrets as plain text over the wire.

     HTTP/1.1 400 Bad Request
      Content-Type: application/json
      Cache-Control: no-store

      {"error"="incorrect_client_credentials"}

 From my point of view, "redirect_uri_mismatch" and 
"bad_verification_code" call for status code 403, whereas 
"incorrect_client_credentials" is the 401 candidate.

3.7.1.  Client Requests Authorization
      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store

      {"code":"74tq5miHKB","user_code":"94248","user_uri":"http%3A%2F%2
      Fwww%2Eexample%2Ecom%2Fdevice","interval"=5}

Why is the user_uri URL-encoded?

3.7.2.  Client Requests Access Token

"authorization_declined"

Why does the spec interpret a request as bad request if the user just 
has declined the authorization? According to rfc2616 the semantics of 
400 is: "The request could not be understood by the server due to 
malformed syntax".

The calling client did not sent a malformed request, it cannot foresee 
or influence this outcome. I would suggest to either use status 403 or 
to return status code 200 for all syntactically correct and authorized 
request and to use another return codes in the response body to detail 
the requests outcome.

4.  Username and Password Flow
4.1.  Client Requests Access Token

As statet in this section's introduction, this flow is intended to 
migrate existing clients from BASIC/DIGEST to OAuth. I therefore would 
suggest to use excactly these HTTP authentication schemes to transfer 
user credentials. This would mean to remove the parameters "username" 
and "password" and to use Authorization headers instead. At Deutsche 
Telekom, we have to deal with that class of clients. Such clients have 
already implemented their credential handling including header 
manipulation. The proposed change would further simplify their migration.

6.  Assertion Flow

This flow is suitable when the client is acting autonomously or on behalf of
    the end-user (based on the content of the assertion used).

Let's assume the assertion attests an end-user's identity. How shall the 
authorization server determine the clients identity in this case? I 
would suggest to add optional client_id/client_secret parameters (or an 
Authorization header) for that case.

7.  Refreshing an Access Token

I would suggest to add an optional "scope" parameter to this request. 
This could be used to downgrade the scope associated with a token.

8.1.  The Authorization Request Header

I consider the name "Token" of the authentication schema much to 
generic. That was also the feedback of all colleagues I talked to about 
the upcoming standard. Why not call it "OAuth2"?

8.2.2.  Form-Encoded Body Parameter

I would suggest to drop this section/feature.

General note: Would it make sense to add explicit format handling to the 
OAuth API? If we envision authorization servers supporting more than one 
token format (e.g. SAML, SWT, ...), the client should given the option 
to request a certain format and responses returning access tokens should 
indicate the format of this token. The OAuth authorization header could 
also have an optional format attribute for the same purpose.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 15:25:14 -0700

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Sunday, May 09, 2010 3:02 PM
> To: OAuth WG ([email-masked]); Eran Hammer-Lahav
> Subject: Comments on draft-ietf-oauth-v2-03.txt
> 

Well, there is already -04... :-) I messed up the section numbers in -03.

> Would'nt it make sense to require "no-cache", too?

No idea.

> Who actually decides to use them? The client or the authorization server or
> both?

Optional means the server gets to decide to include them or not. I think it is pretty clear that optional is decided by the entity constructing the message.

> expires_in
> 
> Why is there information passed back about the access tokens duration but
> not about the refresh tokens duration?

No one asked for that. Is there interest in specifying the authorization duration in addition to the token duration?

> To use status code 400 for all kinds of errors is very generic from my point of
> view. How shall the client implement a dedicated error handling if it cannot
> distinguish different errors. I would suggest either to define error codes (not
> only
> messages) in the spec or to use appropriate HTTP status codes for different
> error conditions, e.g. 401 for unauthorized calls.

It does define error codes and sends them in the 'error' parameter.

> "symmetric" in the context of cryptographical algorithms only. I think "shared
> secret" is sufficient.

Shared secret can be symmetric (password) or asymmetric (key pair).

> BTW: Will Brian's security considerations document be updated to be in sync
> with the draft?

Brian's document was written for WRAP. We need to write a full security review for 2.0 that is structure similarly to OAuth 1.0.

> Does this mean equality? Or just the same base string?

Right now it depends on the server.

> Why not call the "code" Parameter "verification_code"? It's called verification
> code in the text.

Longer for no reason.

> 1) I'm having trouble to understand the meaning of  "if the client identifier
> has a matching secret". Is the assumption underneath that authorization
> servers require this secrets from all clients they have issued a secret to?
> between the client type, clients credentials and the flows a particular client is
> authorized to use?
> 
> I would have expected a clear policy which flows require authentication and
> which not.
> 
> header. First of all because that's the way credential transmission is handled
> in HTTP. Moreover, it better fits with error handling. If the secret is missing or
> wrong, the authorization server can answer with status code 401 and a
> WWW-Authenticate header(s) specifiying mechanism and realms to be used
> by the client in order to authenticate to the server.
> 
> In the long run it gives deployments more freedom to use other mechanisms
> than sending shared secrets as plain text over the wire.
> 
>      HTTP/1.1 400 Bad Request

Conversion mistake.

> Why does the spec interpret a request as bad request if the user just has
> declined the authorization? According to rfc2616 the semantics of
> The calling client did not sent a malformed request, it cannot foresee or
> influence this outcome. I would suggest to either use status 403 or to return
> status code 200 for all syntactically correct and authorized request and to use
> another return codes in the response body to detail the requests outcome.
> 
> As statet in this section's introduction, this flow is intended to migrate
> existing clients from BASIC/DIGEST to OAuth. I therefore would suggest to
> use excactly these HTTP authentication schemes to transfer user credentials.
> This would mean to remove the parameters "username"
> Telekom, we have to deal with that class of clients. Such clients have already
> implemented their credential handling including header manipulation. The
> proposed change would further simplify their migration.

How would you send both client credentials and user credentials? Migration is only one example.

> authorization server determine the clients identity in this case? I would
> suggest to add optional client_id/client_secret parameters (or an

That's the whole point - it doesn't need it because it uses a different trust framework where the client identity is part of.

> This could be used to downgrade the scope associated with a token.

That would be the wrong way to do it given that people will expect to also be able to upgrade scope.

> I consider the name "Token" of the authentication schema much to generic.
> That was also the feedback of all colleagues I talked to about the upcoming
> standard. Why not call it "OAuth2"?

It is meant to be generic. I consider OAuth to be the part of the protocol dealing with getting a token. There will be many new ways to get a token in the future.

> token format (e.g. SAML, SWT, ...), the client should given the option to
> request a certain format and responses returning access tokens should
> indicate the format of this token. The OAuth authorization header could also
> have an optional format attribute for the same purpose.

You mean token format? OAuth defined the token as opaque so that would be counter-productive.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Sun, 9 May 2010 17:52:13 -0700

> No one asked for that. Is there interest in specifying the authorization duration in addition to the token duration?

I have not heard of a scenario where it would be useful to the client to know the refresh token duration.

Unlike the access token where the AS usually sets as expiry time. Authorization could be cancelled at any time for a wide variety of reasons, so there is little knowledge or certainty when it will expire.

> Brian's document was written for WRAP. We need to write a full security review for 2.0 that is structure similarly to OAuth 1.0.

Besides changing some terminology, I would think Brian's doc would be mainly reusable. Perhaps you could insert a version with changes you understand, then people can suggest changes that need to be made.

> Right now it depends on the server.

The spec should clarify that. Suggested wording:

If the client has previously registered a redirection URI with the authorization server, the authorization server MUST verify that the redirection URI received matches the registered URI associated with the client identifier. The components of the redirection URI that must match the registered URI is authorization server dependant.

> That would be the wrong way to do it given that people will expect to also be able to upgrade scope.

Would you elaborate? Would not providing a scope parameter enable any potential change in scope to the access token? The change may be neither an upgrade or downgrade, just different.

> It is meant to be generic. I consider OAuth to be the part of the protocol dealing with getting a token. There will be many new ways to get a token in the future.

I also find the use of Token here.

> You mean token format? OAuth defined the token as opaque so that would be counter-productive.

Not only can the AS support multiple formats, but a PR could support multiple formats. While the token is opaque to the client, the PR is going to need to detect what kind of token was presented in some way. We can make this easier by something in the spec, or defer this to the PR to detect tokens by examining the token. The scope parameter could be used by the AS to determine the token type to be generated.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 22:09:42 -0700

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Sunday, May 09, 2010 5:52 PM

> >> BTW: Will Brian's security considerations document be updated to be
> >> in sync with the draft?
> >
> > Brian's document was written for WRAP. We need to write a full security
> review for 2.0 that is structure similarly to OAuth 1.0.
> 
> Besides changing some terminology, I would think Brian's doc would be
> mainly reusable. Perhaps you could insert a version with changes you
> understand, then people can suggest changes that need to be made.

Since the security section is all non-normative language, it is the least important part on my list. Brian's document is useful but is not something I can work with quickly. If someone wants to take a stab at converting it into a section that can be cut-and-paste into the draft, I would be very happy to incorporate it.
 
> If the client has previously registered a redirection URI with the authorization
> server, the authorization server MUST verify that the redirection URI
> received matches the registered URI associated with the client identifier. The
> components of the redirection URI that must match the registered URI is
> authorization server dependant.

I don't see how that helps... I also don't see why we can't just profile this and decide on how the matching should be done. We have the state parameter to help too.

> Would you elaborate? Would not providing a scope parameter enable any
> potential change in scope to the access token? The change may be neither an
> upgrade or downgrade, just different.

Downgrading scope is the only modification allowed without getting the end-user involved again (or using any of the flows from the beginning). When you refresh a token, you can ask to get a new token with less scope because that will not conflict with the access grant.

> generic.
> >> That was also the feedback of all colleagues I talked to about the
> >> upcoming standard. Why not call it "OAuth2"?
> >
> > It is meant to be generic. I consider OAuth to be the part of the protocol
> dealing with getting a token. There will be many new ways to get a token in
> the future.
> 

Find it...?

> >> General note: Would it make sense to add explicit format handling to
> >> the OAuth API? If we envision authorization servers supporting more
> >> than one token format (e.g. SAML, SWT, ...), the client should given
> >> the option to request a certain format and responses returning access
> >> tokens should indicate the format of this token. The OAuth
> >> authorization header could also have an optional format attribute for the
> same purpose.
> >
> Not only can the AS support multiple formats, but a PR could support
> multiple formats. While the token is opaque to the client, the PR is going to
> need to detect what kind of token was presented in some way. We can
> make this easier by something in the spec, or defer this to the PR to detect
> tokens by examining the token. The scope parameter could be used by the
> AS to determine the token type to be generated.

Token type negotiation is something this group has strongly rejected in the past. I am not sure we can even agree on the right abstraction layer. Either way, there is nothing to stop someone from extending the spec.

And BTW, people can write extensions *now*. This is not aimed at anyone: if you feel strongly about a feature getting little love by this group or facing strong objections, it is your responsibility to draft it and promote it. If you get enough people to like it, we can incorporate it. If not, you can publish it as a companion document.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Sun, 9 May 2010 22:28:35 -0700

> I don't see how that helps... I also don't see why we can't just profile this and decide on how the matching should be done. We have the state parameter to help too.

Don't need to take my wording. We do need to explain the matching.

> Downgrading scope is the only modification allowed without getting the end-user involved again (or using any of the flows from the beginning). When you refresh a token, you can ask to get a new tok…

The client could downgrade and then upgrade again later, which would not change the delegation granted by a user.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 22:40:39 -0700

> Sent: Sunday, May 09, 2010 10:29 PM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
> 
> 
> >>>
> >> the client identifier. The components of the redirection URI that
> >> must match the registered URI is authorization server dependant.
> >
> > I don't see how that helps... I also don't see why we can't just profile this
> and decide on how the matching should be done. We have the state
> parameter to help too.
> 

I agree we need to. Would you like to suggest more detailed rules?

> >>> That would be the wrong way to do it given that people will expect
> >>> to also
> >> be able to upgrade scope.
> >>
> >> potential change in scope to the access token? The change may be
> >> neither an upgrade or downgrade, just different.
> >
> > Downgrading scope is the only modification allowed without getting the
> end-user involved again (or using any of the flows from the beginning).
> When you refresh a token, you can ask to get a new token with less scope
> because that will not conflict with the access grant.
> 

I think that will cause more confusion and problems than help. I am also not sure if there are real use cases for this limited capability.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 10 May 2010 21:12:06 +0200

>> Would'nt it make sense to require "no-cache", too?

I checked back with the rfc2616. I apparently misinterpreted the 
semantics of the field and withdraw the question :-)

> No one asked for that. Is there interest in specifying the authorization duration in addition to the token duration?

Hmmm, is most people's assumption that refresh tokens never expire? Our 
refresh tokens will expire.

And if an application is interested to know the duration of the access 
token it will also consider the refresh tokens duration. Some people 
will probably ignore both data and wait until the access/refresh token 
gets rejected by the service/authorization server. So the error message 
"authorization_expired" of the "refresh" request is much more important.

> Shared secret can be symmetric (password) or asymmetric (key pair).

Which secret is shared in the asymmetric case?

---I copied the folliwing from other messages in this thread---
<Dick Hardt>

>  understand, then people can suggest changes that need to be made.

<Eran Hammer-Lahav>
>Since the security section is all non-normative language, it is the least important part on my list. Brian's document is useful but is not something I can work with>quickly. If someone wants to take a stab at converting it into a section that can be cut-and-paste into the draft, I would be very happy to incorporate it.

Is reformatting this document really sufficient?

I would like to assess the specification's security level from the 
perspective of our usage scenarios. What I miss in the document is a 
threat model of OAuth along with relations between possible threats and 
respective countermeasures. So do I have to built this model on my own? 
Or will there be a joint effort?

>> Why not call the "code" Parameter "verification_code"? It's called verification

  for  the  sake  of  clarity?

>> I would have expected a clear policy which flows require authentication and

Did you miss this question?

>> another return codes in the response body to detail the requests outcome.

Did you miss this question?

> How would you send both client credentials and user credentials? Migration is only one example.

I withdraw this proposal. As I have written in my response to "Open 
Issues: Group Survey": I would leave the end-user credential handling as 
is in favour of using Authorization headers for client authentication 
only. This will convey clarity.

> That's the whole point - it doesn't need it because it uses a different trust framework where the client identity is part of.

Could you please elaborate on the term trust framework? A SAML assertion 
contains at most one identity but we need two of them. Where should the 
second identity come from?

> That would be the wrong way to do it given that people will expect to also be able to upgrade scope.

What would be the right way?

> It is meant to be generic. I consider OAuth to be the part of the protocol dealing with getting a token. There will be many new ways to get a token in the future.

That's interesting! I consider the authentication scheme the major 
contribution of OAuth since it allows for a standardized way of service 
interaction. So 3rd party software components can be integrated into a 
companies infrastructure (incl. AS) w/o customization. Moreover, as you 
pointed out, there will be many other ways to get tokens in the future.

> You mean token format? OAuth defined the token as opaque so that would be counter-productive.

I dont't mean OAuth shall define token formats. I just ask for a way to 
request tokens in a particular format and pass such meta data from AS to 
resource server via the client. Why is that counter-productive? 
Otherwise the resource server has to implement some token format discovery.

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 13:02:23 -0700

> I think that will cause more confusion and problems than help. I am also not sure if there are real use cases for this limited capability.

Not sure how downgrade then upgrade would work. I think down/up grade
is always relative to the scope associated with the refreshed token.
The refresh token never changes, so the base scope is always the same.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 13:07:09 -0700

On Sun, May 9, 2010 at 3:01 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> I would suggest to use JSON encoding here, since the URI fragment is handled
> by a client more or less like a response result.

Evan mentioned that returning JSON in this case is a bad idea because
it is very hard to safely parse JSON in JavaScript.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 13:16:06 -0700

> I don't see how that helps... I also don't see why we can't just profile this and decide on how the matching should be done. We have the state parameter to help too.

I also think the spec should specify how the matching should be done.

If left up to the authz server then a client that designs its OAuth 2
implementation will have to assume that all authz servers will do
strict equality matching, otherwise it may not be able to interact
with some servers.

For example, if the client assumes that it can use load balancing by
varying the first part of the host name, and this may work with the
fist authz server it integrate with, later this client will not be
able to interact with an authz server which does strict matching on
host name. And changing the load balancing architecture once deployed
could be very hard.

Since there is a state parameter maybe it is enough to allow wild
cards only in the domain name of the callback URI.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 13:18:21 -0700

>> I also find the use of Token here.

I also think that "token" is too generic. Many new ways to get a token
also mean many types of tokens. An OAuth 1 access token is not the
same as an OAuth 2 access token.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 10 May 2010 22:20:46 +0200

> it is very hard to safely parse JSON in JavaScript.

Native JSON support makes it easier.

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 10 May 2010 17:43:21 -0700

On Mon, May 10, 2010 at 1:20 PM, Torsten Lodderstedt <
[email-masked]> wrote:

>>> handled

Only for newer browsers - every web site that wants to work on older browser
would need a JSON parsing library.

Think that people on the form encoding or JSON thread were in rough
agreement that redirect_uri responses should be form encoded.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 May 2010 19:53:33 -0700

Propose text.

EHL

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 1:16 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG ([email-masked])
> implementation will have to assume that all authz servers will do strict
> equality matching, otherwise it may not be able to interact with some
> servers.
> 
> For example, if the client assumes that it can use load balancing by varying
> the first part of the host name, and this may work with the fist authz server it
> integrate with, later this client will not be able to interact with an authz server
> which does strict matching on host name. And changing the load balancing
> architecture once deployed could be very hard.
> 
> Since there is a state parameter maybe it is enough to allow wild cards only in
> the domain name of the callback URI.
> 
> Marius

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 11 May 2010 15:04:28 -0700

On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu <[email-masked]>wrote:

> authorization
> > I don't see how that helps... I also don't see why we can't just profile
> this and decide on how the matching should be done. We have the state
> parameter to help too.
>

I think this we should leave this matching undefined for now - since you
have to preregister with every site, you will have provider-specific logic
anyway. This will be much more important when we have a discovery mechanism
for callback URLs.

Also note that for the load balancing use case a client can set up their own
redirector. This is dangerous (open redirectors are very easy to create),
but if you're doing load balancing you can probably get the redirection
logic right.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 11 May 2010 15:13:47 -0700

> anyway. This will be much more important when we have a discovery mechanism

If we leave undefined then that is the same as enforcing strict
equality matching. Then let's make that explicit. Are we OK with that?

A client that eventually wants to interact with several authz servers
will have to assume the "greatest common divisor", which is strict
matching.

Marius

---

From: Luke Shepard <[email-masked]>
Date: Tue, 11 May 2010 23:31:58 -0700

FWIW, Facebook does not do strict equality matching on redirect_uri. We accept any redirect_uri that has either:

- its prefix is the registered url
- or it is a special facebook.com/xd_proxy.php url, with an origin parameter that has a prefix on the registered url

I think that the spec should leave the matching up to the server.

---

From: Raffi Krikorian <[email-masked]>
Date: Wed, 12 May 2010 07:39:31 +0100

twitter is working on a version where we will actually allow the
specification of an explicit array of registered URIs, and we do strict
matching against the elements of that array to see if any match.  we thought
of allowing just subdomain globbing and wildcards, but that seemed
problematic for GAE like situations....

On Wed, May 12, 2010 at 7:31 AM, Luke Shepard <[email-masked]> wrote:

> - or it is a special facebook.com/xd_proxy.php url, with an origin
> parameter that has a prefix on the registered url
>
> >> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu <
> [email-masked]>
> >> wrote:
> >>>
> >>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav <
> [email-masked]>
> >>> wrote:
> >>>>

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 12 May 2010 09:34:54 -0700

If I understand correctly, Twitter does strict matching (against a
list) and Facebook does prefix matching.

If I am a client and want to integrate with Facebook only, I may take
advantage of the prefix matching and rely on that.

What if at some point in the future I now want to integrate with
Twitter as well? I can't. At least not without rewriting my whole
OAuth 2 infrastructure.

Because of that, if I really want to be able to work with any OAuth 2
authz sever I can only assume strict matching. Do we want to tackle
this problem or let clients figure it out (some of them the hard way)?

Marius

On Tue, May 11, 2010 at 11:39 PM, Raffi Krikorian <[email-masked]> wrote:
>> >> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu
>> >> <[email-masked]>
>> >> wrote:
>> >>>
>> >>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav
>> >>> <[email-masked]>
>> >>> wrote:
>> >>>>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 12 May 2010 19:06:07 -0700

> Propose text.

Tried to write some text, but still not sure what the right solution is.

redirect_uri matching is done in two flows: Web Server and User-Agent.

In Web Server the matching issue can be avoided by always requiring
redirect_uri on the initial request, and require authz servers not to
match against a pre-registered one, and then do strict matching when
the access token is requested.

In User-Agent, matching must be done between pre-registered and the
one sent with the request. Here I would suggest strict matching (which
boils down to no requirement to send redirect_uri if it was
pre-registered). For this flow, does anyone see the need for wild card
domain matching or for path prefix matching?

If we cannot get to an agreement, maybe the spec can at least advise
clients to assume strict matching since this assures the largest
compatibility?

Does it help to propose text if there is no agreement?

Marius

>> <[email-masked]> wrote:
>> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 10:58:44 -0700

> Sent: Monday, May 10, 2010 12:12 PM

> >> verification code in the text.

Anyone with thoughts on this?

> >> identifier has a matching secret". Is the assumption underneath that
> >> authorization servers require this secrets from all clients they have issued
> a secret to?

Yes.

> >> between the client type, clients credentials and the flows a
> >> particular client is authorized to use?

Yes, they are (I think this is the compromise on native apps).

> >> I would have expected a clear policy which flows require
> >> authentication and which not.

Suggest text.

> >> The calling client did not sent a malformed request, it cannot
> >> foresee or influence this outcome. I would suggest to either use
> >> status 403 or to return status code 200 for all syntactically correct
> >> and authorized request and to use another return codes in the response
> body to detail the requests outcome.
> >>
> 

No. Just ignored it because I need to go over all the HTTP status codes and error messages and clean it all up. Its incomplete at best right now.

> What would be the right way?

Allow the client to include an access token when asking for additional scope (via a normal flow) so that resulting token will include the scope of both new and old scopes.

> pointed out, there will be many other ways to get tokens in the future.

I'm not married to the name. I dislike 'OAuth2' because it is wrong to put a version number in the name. We can potentially reuse 'OAuth' but I'm opposed to using the 'oauth_version=2.0' parameter specified in OAuth 1.0. So we can just update 1.0 (since it is now an RFC) to note that 1.0 uses the oauth_ prefix for parameters and deprecate the oauth_version parameter. Or something like that.

I'm also open to new suggestions. But I think 'Token' is very descriptive (but I agree it does depend on your view of what is OAuth - I think it is really just the collection of flows).

> Otherwise the resource server has to implement some token format

Yes it does.

EHL

---

From: <[email-masked]>
Date: Thu, 13 May 2010 22:49:37 +0200

> would be counter-productive.
My comment on that comment: 
	"opaque" for oauth could mean that oauth does not handle certain
types of tokens specially.
	I think this is not an argument to reject the request that the
client could ask for one token format.
	I think a client should be allowed to ask for a token format but
oauth should not handle any format specially.
	Oauth should transport all tokens but the format is something
agreed upon between client, authorization server and resource server.
	Requesting a token format is also a means to migrate from one
token format to the next.

>> Otherwise the resource server has to implement some token format

My comment on that comment:
If we burden the resource server with token format discovery then why
not burdon the authorization server with client_credential discovery?
Currently if client_secrets are used the client maker has to register
the client with the authorization server maintainer to get the
client_secret and such. This agreement is beyond the scope of oauth. I
think client and authorization server should be allowed to agree on any
authentication scheme not just shared secrets.

My request is to just rename client_secret to client_credential; both of
them know what they agreed upon whether it is a shared secret or
something else. 

-Axel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eran Hammer-Lahav
Sent: Thursday, May 13, 2010 7:59 PM
To: Torsten Lodderstedt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

Yes.

Suggest text.

> Did you miss this question?

No. Just ignored it because I need to go over all the HTTP status codes
and error messages and clean it all up. Its incomplete at best right
now.

to also
> What would be the right way?

Allow the client to include an access token when asking for additional
scope (via a normal flow) so that resulting token will include the scope
of both new and old scopes.

> pointed out, there will be many other ways to get tokens in the
future.

I'm not married to the name. I dislike 'OAuth2' because it is wrong to
put a version number in the name. We can potentially reuse 'OAuth' but
I'm opposed to using the 'oauth_version=2.0' parameter specified in
OAuth 1.0. So we can just update 1.0 (since it is now an RFC) to note
that 1.0 uses the oauth_ prefix for parameters and deprecate the
oauth_version parameter. Or something like that.

I'm also open to new suggestions. But I think 'Token' is very
descriptive (but I agree it does depend on your view of what is OAuth -
I think it is really just the collection of flows).

Yes it does.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 11:20:29 -0700

> I think that the spec should leave the matching up to the server.

If the matching is left to an arbitrary, server defined algorithm, we lose
interop since a client implementation may make assumptions on what may be
allowed in the redirect_uri at one AS and then not be able to work with
another AS that is more restrictive.

As this is a security feature, I'd like to hear the options from the
security oriented participants with experience here.

Allen / Brian?

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 17 May 2010 08:29:20 -0700

I'd like to get a standard for redirect URI matching, but think this may not
be feasible - we are leaving the callback URI registration mechanism
undefined and I've heard a number of different mechanisms that companies
want to support.

I think we should leave the matching undefined, possibly with a SHOULD for
the most common matching mechanism (URL prefix?)

I'm not hugely worried about incompatibilities between different AS on this
front:
1. Clients will push us strongly towards compatible implementations.
2. Clients can always set up a redirector if needed for a specific AS (as an
aside - we need a document detailing how to build a redirector properly
without becoming an open redirector).

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 17 May 2010 08:53:19 -0700

> without becoming an open redirector).

Isn't this saying that clients can always implement strict matching
and live with that? Why not require it then?

Marius

---

From: Brian Eaton <[email-masked]>
Date: Mon, 17 May 2010 10:49:33 -0700

> security oriented participants with experience here.

We can do a session at IIW on this if people want.  There are a few
different use-cases to consider:

- installed applications using the js profile or the web app profile
   It doesn't matter what you do, you can't authenticate the installed
application.  My recommendation here is to do something like what
we've done with OAuth for installed apps [1].

- registered web apps with a secure client-secret
  You can allow *any* callback URL on the redirect.
  The callback URL is authenticated using the client-secret.
  We should all do strict equality matching when exchanging the
verification code for refresh token and access token.

- js profile, or web app profile where you don't completely trust the
registration or the security of the client-secret
  We've got lots of service-provider specific behavior here.
Unfortunately most service providers don't seem to be willing to
change (or in some cases even document) what they are doing.  So we're
doomed unless we can get consensus from service providers that there
needs to be consensus. =)

Logic I've seen includes:
- regular expressions
- any callback URL on the fully-qualified hostname
- any callback URL on a domain name.
- fixed callback URL path, arbitrary callback URL query
- fixed callback URL path, fixed callback URL query, one query
parameter (wrap_state, or whatever we called it =) allowed to vary
- any callback URL path under a particular directory

I tried to summarize the risks in the security considerations I wrote
up a few weeks ago.  Check out the section on "Authentication
Techniques" and "Web App Delegation Profile - Security
Considerations".

Cheers,
Brian

[1] http://code.google.com/apis/accounts/docs/OAuthForInstalledApps.html
[2] http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 18 May 2010 09:11:19 -0700

> and live with that? Why not require it then?

No, don't think so.

Clients will use redirect behavior that works with their current provider,
and deal with strict matching when/if it comes up.

I'm pretty sure that norms will evolve, but also pretty sure that we won't
agree right now.