Subject: [OAUTH-WG] review of draft-ietf-oauth-v2-16

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 01 Jun 2011 12:43:19 -0600

Last week I completed a review of draft-ietf-oauth-v2-16. Here are some
comments.

MAJOR ISSUES...

Throughout the document, the various parameters (e.g., client_secret and
client_id) are essentially undefined. There is no text about the length
of these parameters, the allowable characters (e.g., alpha and digits
only, all ASCII characters, full Unicode), internationalization
considerations, preparation and comparison of strings, etc. I don't see
how developers will build interoperable implementations without clear
guidance here.

Also, the scope parameter still strike me as extremly vague. Can we at
least define the word "scope" and provide a few examples of how the
parameter might be used?

No rules are provided for URI matching (e.g., in Section 4.1 the
redirection URI received needs to be checked against the URI used to
redirect the client, but not guidance is provided). Perhaps a reference
to RFC 3986 is in order here. Here also internationalization concerns
might need to be covered (e.g., are IRIs allowed?).

4.1.2. Authorization Response

OLD:
         If an
         authorization code is used more than once, the authorization
         server MAY revoke all tokens previously issued based on that
         authorization code.

NEW:
         If an
         authorization code is used more than once, the authorization
         server SHOULD revoke all tokens previously issued based on that
         authorization code.

RATIONALE: MAY seems weak here.

10.2. Client Impersonation

   The authorization server SHOULD require the client to pre-register
   its redirection URI and validate the value of the "redirect_uri"
   against the pre-registered value.

How does this validation occur?

OLD:
   The authorization server SHOULD issue access tokens with limited
   scope and duration to clients incapable of authenticating.

NEW:
   If the authorization server issues access tokens to clients
   that are incapable of authenticating, the scope and duration of
   such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?

10.3. Access Token Credentials

   The client SHOULD request access token credentials with the minimal
   scope and duration necessary.

Is this enfoced by the authorization server?

10.6. Endpoints Authenticity

   In order to prevent man-in-the-middle and phishing attacks, the
   authorization server MUST implement and require TLS with server-side
   authentication in all exchanges.  The client MUST verify the
   authorization server's TLS certificate, as well as the respective
   certificate chain.

We need a reference to RFC 2818 here since it defines server
verification procedures for HTTP. (Same for Section 10.8.)

10.9. Authorization Codes

   Authorization codes SHOULD be short lived and MUST be single use.  If
   the authorization server observes multiple attempts to exchange an
   authorization code for an access token, the authorization server
   SHOULD revoke all access tokens already granted based on the
   compromised authorization code.

Is there a good reason why the authorization server would not revoke all
the access tokens? If not, change to MUST.

MINOR ISSUES...

1.4.1. Authorization Code

OLD:
   Before directing the resource owner back to the client with the
   authorization code, the authorization server authenticates the
   resource owner and obtains authorization.  Because the resource owner
   only authenticates with the authorization server, the resource
   owner's credentials are never shared with the client.

NEW:
   Before directing the resource owner back to the client with the
   authorization code, the authorization server authenticates the
   resource owner and obtains authorization.  Because the resource owner
   only authenticates with the authorization server, the resource
   owner's credentials at the resource server are never shared with the
   client.

RATIONALE: could the resource owner have credentials at the
authorization server?

1.4.2. Implicit

OLD:
   Implicit grants improve the responsiveness and efficiency of some
   clients (such as a client implemented as an in-browser application)
   since it reduces the number of round trips required to obtain an
   access token.

NEW:
   Implicit grants improve the responsiveness and efficiency of some
   clients (such as a client implemented as an in-browser application)
   since they reduce the number of round trips required to obtain an
   access token.  However, service providers need to weigh this
   convenience against the security properties of implicit grants
   (e.g., the fact that client authentication is not possible).

RATIONALE: I think it would be good to mention that there's a balance
here between convenience and security.

1.7 Notational Conventions

I think it would be good to add an informational reference to RFC 4949
here, and to check our usage of certain terms against the definitions in
that spec. Proposed text:

   Certain security-related terms are to be understood in the sense
   defined in [RFC4949]; such terms include, but are not limited to,
   "attack", "authentication", "authorization", "certificate",
   "confidentiality", "credential", "encryption", "identity",
   "sign", "signature", "trust", "validate", and "verify".

2.1. Authorization Endpoint

OLD:
   Request and response parameters MUST NOT repeat more than once,
   unless noted otherwise.

NEW:
   Request and response parameters MUST NOT be included more than once,
   unless noted otherwise.

4.1.2.1. Error Response

OLD:
   error_description
         OPTIONAL.  A human-readable text providing additional
         information, used to assist in the understanding and resolution
         of the error occurred. [[ add language and encoding information
         ]]

NEW:
   error_description
         OPTIONAL.  Descriptive text providing additional information,
         used to assist in the understanding and resolution of the
         error that has occurred.  If included, it MUST be used only
         to provide descriptive or diagnostic information that
         supplements the meaning of an existing HTTP error code.  It
         MUST NOT be interpreted programmatically by an application and
         MUST NOT be used as the error message presented to a human
         user, but MAY be used by application developers for debugging
         purposes.

RATIONALE: If the error_description is not intended for humans and is to
be used only by developers for debugging purposes, then we don't need
language tags. (As explained in RFC 2277, "internationalization is for
humans"; yes, developers are people too...)

4.2. Implicit Grant

This section uses the term "web server"; I suggest "resource server" for
consistency.

7.1. Access Token Types

OLD:
   The access token type provides the client with the information
   required to successfully utilize the access token to make a protected
   resource request (along with type-specific attributes).  The client
   MUST NOT use an access token if it does not understand the token
   type.

NEW:
   The access token type provides the client with the information
   required to successfully utilize the access token to make a protected
   resource request (along with type-specific attributes).  The client
   MUST NOT use an access token if it does not understand or does not
   trust the token type.

RATIONALE: An application could understand a given token type but not
trust it (or not trust it from the sender).

8.1. Defining Access Token Types
8.2. Defining New Endpoint Parameters

Mention that the ALPHA and DIGIT rules come from RFC 5234.

Peter

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

---

From: Brian Eaton <[email-masked]>
Date: Wed, 1 Jun 2011 12:06:28 -0700

Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point
about client impersonation and installed apps.  The cuirrent text is
unrealistic, but your request would push it the wrong way.  CC'ing Torsten
as well.

---------------------
OLD:

NEW:

---------------------

We are most definitely recommending that clients that have no way of
authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user
authentication to anything stronger than a password.  Client certificates,
one time passwords, risk based authentication, throw it all out the window.
 If you're going to let installed apps authenticate with just a password,
nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user
authentication, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are
important, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary
credentials to native apps.  That's not practical.  Native apps end up
needing permanent or near-permanent credentials.  Expirations need to be
measured in months.  And the credentials are going to be issued to stock
IMAP and XMPP clients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers,
they are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create
flows that bridge from those managed credentials to temporary access
credentials.

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 02 Jun 2011 11:09:45 +0200

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security 
problem at all. If we would follow this line, every e-Mail client out 
there would be considered insecure because the client itself is never 
authenticated. Not even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization 
scenarios) is an improvement over classical approaches. But I do not see 
a degration in security if it is not applicable. As long as the _user_ 
authorizes the client's access (and the duration of the token) and is 
able to revoke the tokens at any time, the situation is much better than 
with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
> Hey Peter -
>
> I haven't read all of your comments yet, but I wanted to clarify one 
> point about client impersonation and installed apps.  The cuirrent 
> text is unrealistic, but your request would push it the wrong way. 
>  CC'ing Torsten as well.
>
> ---------------------
> OLD:
> That's a horrible security problem, because it means you cannot 
> upgrade user authentication to anything stronger than a password. 
>  Client certificates, one time passwords, risk based authentication, 
> throw it all out the window.  If you're going to let installed apps 
> authenticate with just a password, nothing else you do to improve 
> authentication is going to help.
>
> needing permanent or near-permanent credentials.  Expirations need to 
> be measured in months.  And the credentials are going to be issued to 
> stock IMAP and XMPP clients that don't have any way of authenticating 
> themselves.
>
> b) the refresh tokens aren't sent directly to the IMAP and XMPP 
> servers, they are restricted to authorization servers.
> c) if you've got a managed machine (think Kerberos logins), you can 
> create flows that bridge from those managed credentials to temporary 
> access credentials.
>
> Cheers,
> Brian

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 2 Jun 2011 10:51:19 -0500

I agree with Brian.
One of the use cases that relies on the issuing tokens to an unauthenticated client is Mobile App (http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01#section-3.4). A use case's requirement is that "authorization shall be valid for a prolonged duration". Such long-term  authorization relies on the use of the refresh tokens.

Zachary

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Wednesday, June 01, 2011 3:06 PM
To: Peter Saint-Andre
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point about client impersonation and installed apps.  The cuirrent text is unrealistic, but your request would push it the wrong way.  CC'ing Torsten as well.

---------------------
OLD:

NEW:

We are most definitely recommending that clients that have no way of authenticating are issued long-lived credentials to access user data.

That's a horrible security problem, because it means you cannot upgrade user authentication to anything stronger than a password.  Client certificates, one time passwords, risk based authentication, throw it all out the window.  If you're going to let installed apps authenticate with just a password, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are important, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credentials to native apps.  That's not practical.  Native apps end up needing permanent or near-permanent credentials.  Expirations need to be measured in months.  And the credentials are going to be issued to stock IMAP and XMPP clients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create flows that bridge from those managed credentials to temporary access credentials.

Cheers,
Brian

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 2 Jun 2011 14:40:15 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Thursday, June 02, 2011 5:10 AM
> To: Brian Eaton
> Cc: OAuth WG

Well, not to belabor this point :)  but in Kerberos it is the proof of possession of the client secret key which _is_ the authentication mechanism. There is also PKINIT (RFC4556) which can be used to "pre-authenticate" the user via Diffie-Hellman (anonymous) or a full X509 certificate.

However, there is indeed the assumption in Kerberos/RFC4120 (and in the original Needham-Schroeder protocol) that the "client" can keep secrets.

/thomas/

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 02 Jun 2011 15:31:10 -0400

Actually, for the devices that use smart cards (mobile devices, in 
particular), this assumption is quite appropriate. 

Igor

Thomas Hardjono wrote:
>> ....
> ...
> _______________________________________________
>
>

---

From: Brian Eaton <[email-masked]>
Date: Thu, 2 Jun 2011 12:45:21 -0700

On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono <[email-masked]> wrote:

> Well, not to belabor this point :)  but in Kerberos it is the proof of
> possession of the client secret key which _is_ the authentication mechanism.
> There is also PKINIT (RFC4556) which can be used to "pre-authenticate" the
> user via Diffie-Hellman (anonymous) or a full X509 certificate.
>

The kerberos notion of "client" is not the same thing as the OAuth notion of
"client".  The "client" in kerberos maps to the OAuth "user".  The "client"
in OAuth is the application the user is using.

Kerberos does not, for example, try to authenticate the kinit binary.  It
just tries to authenticate the person using the kinit binary.

Kerberos does have a notion of forwardable service tickets that authenticate
both the user and the service they are using; that's a much closer match to
what OAuth2 does.

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 2 Jun 2011 16:13:22 -0400

Thanks Igor,

If you bring smartcards into the picture, then it's a different
ballgame :)

If mobile phones are assumed to have smartcards (which is increasingly
true today via USIMs), then OAUTH can assume that native apps (running
on the phones) may have access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.

/thomas/

__________

> -----Original Message-----
> From: Igor Faynberg [mailto:[email-masked]]
> Sent: Thursday, June 02, 2011 3:31 PM
> To: Thomas Hardjono
> Cc: Torsten Lodderstedt; OAuth WG
> > However, there is indeed the assumption in Kerberos/RFC4120 (and
in
> the original Needham-Schroeder protocol) that the "client" can keep
> secrets.
> >
> > /thomas/
> >
> >
> >

---

From: Phillip Hunt <[email-masked]>
Date: Thu, 2 Jun 2011 13:20:33 -0700

The notion of client instance ids (eg as suggested) by USIMs suggested may be a slightly different identify then envisioned by client_id. 

I have mentioned the same issue before of identifying software separately from deployment instances which such a strong credential would map to. 

They likely has to be addressed post 2.0. 

Phil

On 2011-06-02, at 13:13, Thomas Hardjono <[email-masked]> wrote:

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

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 2 Jun 2011 16:24:22 -0400

> __________________________________________
> 
> From: Brian Eaton [mailto:[email-masked]]
> Sent: Thursday, June 02, 2011 3:45 PM
> To: Thomas Hardjono
> possession of the client secret key which _is_ the authentication
> mechanism. There is also PKINIT (RFC4556) which can be used to "pre-
> authenticate" the user via Diffie-Hellman (anonymous) or a full X509
> certificate.
> 
> The kerberos notion of "client" is not the same thing as the OAuth
> notion of "client".  The "client" in kerberos maps to the OAuth
> "user".  The "client" in OAuth is the application the user is using.
> 
> Kerberos does not, for example, try to authenticate the kinit
> binary.  It just tries to authenticate the person using the kinit
> binary.

Oh ok, now I get what "authenticating the client" means here. My bad. Perhaps the term "authenticating" is not accurate. Maybe "integrity verification" of client code is a better phrase.

And yes, integrity-verification of the kinit binary in MIT Kerberos is not performed prior to execution (in Linux-based systems). 

Actually, generally speaking integrity-verification of binaries (either in store/disk or during run-time) is not the job of a client code like kinit. The OS should be doing this.

Thanks.

/thomas/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 02 Jun 2011 23:01:16 +0200

in my opinion, the problem with client authentication is more the secure distribution of the secret than the storage. How should a USIM help here?

regards,
Torsten.

Thomas Hardjono <[email-masked]> schrieb:

Thanks Igor,

/thomas/

__________

in
> >_____________________________________________

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 02 Jun 2011 17:34:57 -0400

Absolutely!  In fact, client_id,  should be presumed to be TOTALLY 
different from the USIM (or ISIM) ID.  The correlation of IDs is the 
network's job. (Hui-Lan and I, along with two other researchers, 
described how this can be done in a Bell Labs Technical Journal paper: 
http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/pdf.)

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 02 Jun 2011 17:43:48 -0400

As far the authentication goes, what I had in mind was that the network 
provider could authenticate  the end-user. Alternatively, an application 
(not necessarily the USIM) on the smart card could hold the secret and 
perform all cryptographic operations (what Thomas calls crypto-store). 
In either case, only the provider and the card would share the secret.

Igor

Torsten Lodderstedt wrote:
> in my opinion, the problem with client authentication is more the 
> secure distribution of the secret than the storage. How should a USIM 
> help here?
>
> regards,
> Torsten.
>
>
>
>     > particular), this assumption is quite appropriate.>
>
>     > Igor
>     > 
>     > Thomas Hardjono wrote:
>     > >> ....
>     > > ...
>     > >
>     ------------------------------------------------------------------------
>
>     > >
>     > >
>         
>

---

From: Dave Nelson <[email-masked]>
Date: Thu, 2 Jun 2011 17:51:31 -0400

On Thu, Jun 2, 2011 at 4:24 PM, Thomas Hardjono <[email-masked]> wrote:

> Oh ok, now I get what "authenticating the client" means here. My bad.
> Perhaps the term "authenticating" is not accurate. Maybe "integrity
> verification" of client code is a better phrase.

It *may* include integrity verification of the client binary, but in
the use cases I'm envisioning it's more a verification of the identity
of the application publisher, and that the publisher has a business
relationship with the OAuth authorization provider, such as a
developer registration.  In some case that matters.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Jun 2011 16:01:33 -0600

On 6/1/11 1:06 PM, Brian Eaton wrote:
> point about client impersonation and installed apps.  The cuirrent text
> is unrealistic, but your request would push it the wrong way.  CC'ing
> Torsten as well.
> 
> ---------------------
> OLD:

I think I might have misunderstood that text -- I took it to be talking
about the client's authentication with the authorization server, not the
client's authentication with the resource server.

Peter

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

---

From: Brian Eaton <[email-masked]>
Date: Thu, 2 Jun 2011 15:11:35 -0700

> client's authentication with the resource server.

No, you understand perfectly.  We're talking about giving extremely powerful
and near-permanent credentials to clients we can't authenticate.  We're
pretty sure this is a good idea. =)

We authenticate the user and get their consent.  If they say yes, the client
gets something that is almost, but not quite, equivalent to an alternate
password for the user.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Jun 2011 18:08:06 -0600

On 6/2/11 4:11 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> No, you understand perfectly.  We're talking about giving extremely
> powerful and near-permanent credentials to clients we can't
> authenticate.  We're pretty sure this is a good idea. =)
> 
> We authenticate the user and get their consent.  If they say yes, the
> client gets something that is almost, but not quite, equivalent to an
> alternate password for the user.

Sure, that's the classic OAuth pattern.

I think the SHOULD we had originally is probably fine -- with the
understanding that "SHOULD" means "you really ought to do this unless
you have a good reason not to". I think one such really good reason
might be a authorization server that doesn't allow unauthenticated
clients (i.e., clients that are not pre-registered or don't have
certificates or whatever).

Peter

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

---

From: Brian Eaton <[email-masked]>
Date: Thu, 2 Jun 2011 17:48:42 -0700

> certificates or whatever).

Really?  What are you thinking of as "limited duration" credentials for a
desktop application?

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Jun 2011 20:13:41 -0600

On 6/2/11 6:48 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre <[email-masked]
> Really?  What are you thinking of as "limited duration" credentials for
> a desktop application?

I'm not thinking about your use case, but things like enterprise
deployments in high-security environments where every person and every
software application has a certificate or is otherwise provisioned for
authentication with the authorization server.

However, I'm not saying we should change or add any text to the spec,
because the SHOULD allows such deployments to not issue tokens to
clients that are incapable of authenticating. So I don't particularly
see a reason to keep discussing the matter.

Peter

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

---

From: Brian Eaton <[email-masked]>
Date: Thu, 2 Jun 2011 19:38:14 -0700

> authentication with the authorization server.

I actually care quite a bit about that use case. =)

> see a reason to keep discussing the matter.

OK, I understand the confusion now.

I'm going to continue to push for the security considerations to be broken
up more cleanly by use case, in part to avoid confusion like this.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Jun 2011 20:53:23 -0600

On 6/2/11 8:38 PM, Brian Eaton wrote:
> On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre <[email-masked]

I'm happy to hear it. There are so many interesting use cases in the
world, aren't there? ;-)

> I'm going to continue to push for the security considerations to be
> broken up more cleanly by use case, in part to avoid confusion like this.

Probably a good idea.

Peter

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 03 Jun 2011 08:09:13 +0200

Got it. End-user authentication via USIM is indeed secure (and convenient).

regards,
Torsten.

Igor Faynberg <[email-masked]> schrieb:

Igor

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 12:19:47 -0700

I agree to the extent that the user can be trusted to know how they got to the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited in the information it can offer the user to make the decision. It is extremely hard to come up with language that will tell the user to only approve the application, claiming to be X, if they got here from X directly. There might be ways to improve security a bit using Origin header etc. but overall, if the client is not authenticated, the authorization server can't really describe it to the user.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Not authenticating the client does not directly create a security problem at all. If we would follow this line, every e-Mail client out there would be considered insecure because the client itself is never authenticated. Not even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scenarios) is an improvement over classical approaches. But I do not see a degration in security if it is not applicable. As long as the _user_ authorizes the client's access (and the duration of the token) and is able to revoke the tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 16 Jun 2011 10:37:48 +0200

The ability to describe a client to the user does not depend on the authentication but on the identification of the client and the meta data available to the authz server. The only difference between identified and authenticated clients is the trust level the authz server has regarding the client's identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:[email-masked]]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

EHL

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 16 Jun 2011 08:32:55 -0700

Easier said than done. If you don't have strong trust, giving the user hints will cause more harm than good.

EHL

From: Lodderstedt, Torsten [mailto:[email-masked]]
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: AW: [OAUTH-WG] review of draft-ietf-oauth-v2-16

regards,
Torsten.

EHL

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 16 Jun 2011 12:34:50 -0500

I agree with the statement. Authorization server provides information about a client to a user based on the client's identifier, which client has presented to the server. If authorization server cannot validate the client's identity claim, it must make the user aware.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

regards,
Torsten.

EHL

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 16 Jun 2011 10:51:54 -0700

This is nice on paper but doesn't work.

The user will see the client name or logo and will not read any of the fine print. We know this as a fact. If you can't validate the client identifier, you should not show the user any information about the client that you cannot vouch for. Disclaimers and scary pages are useless.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:[email-masked]]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

regards,
Torsten.

EHL

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 10:55:07 -0700

On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> This is nice on paper but doesn’t work.
>

I have to agree.  It doesn't matter what the spec says on this point.  No
one is going to take advice from the spec about what the text on their
approval page ought to say.

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 16 Jun 2011 14:50:38 -0500

> If you can't validate the client identifier, you should not show the user any information about the client that you cannot vouch for.
According to the flow described in section 1.2, authorization by the resource owner (user) is done before the authorization server authenticates the client.
How authorization server can validate the client's identifier before authenticating the client?

Zachary
________________________________
From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, June 16, 2011 1:52 PM
To: Zeltsan, Zachary (Zachary); 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

EHL

regards,
Torsten.

EHL

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 16 Jun 2011 13:23:31 -0700

The user should be informed and in control, but there is a limit to how much information you can give with confidence. My point is that it is really hard to provide the user with trustworthy information without client registration and secure client credentials or pre-registered callback.

If you have a client identifier without secret (via the authentication code) or registered callback, that client identifier is useless and must not be used.

EHL

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 16, 2011 11:24 AM
To: Eran Hammer-Lahav; Lodderstedt, Torsten; Brian Eaton
Cc: OAuth WG
Subject: AW: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I thought keeping the user informed and in control are core principles of oAuth? Do you suggest not informing the user is better than stating something like: "the client should be XXX, accept the request only if you are sure ...."

regards,
Torsten.

Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland

________________________________
From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 16 Jun 2011 08:32:55 -0700
To: Lodderstedt, Torsten<[email-masked]>; Torsten Lodderstedt<[email-masked]>; Brian Eaton<[email-masked]>
Cc: OAuth WG<[email-masked]>
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

EHL

regards,
Torsten.

EHL

In my opinion, OAuth client authentication (in delegated authorization scenarios) is an improvement over classical approaches. But I do not see a degration in security if it is not applicable. As long as the_user_ authorizes the client's access (and the duration of the token) and is able to revoke the tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 16 Jun 2011 13:25:12 -0700

If this is an implicit grant, using the redirection URI registered before. If this is the authorization code, the server knows that the client will have to present a secret later to get access, so it can make that information available with confidence. If someone else is asking using a stole identifier, they will not go far without the secret, and the user data will remain safe.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:[email-masked]]
Sent: Thursday, June 16, 2011 12:51 PM
To: Eran Hammer-Lahav; 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Zachary

EHL

regards,
Torsten.

EHL

regards,
Torsten.

---------------------
OLD:

NEW:

Cheers,
Brian