Subject: [OAUTH-WG] Issue 15, new client registration

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 20 Jul 2011 22:56:09 +0200

2.1 Client types

I'm struggeling with the new terminology of "private" and "public" 
clients. In my perception, the text just distinguishes clients which can 
be authenticated and such which cannot. This is fine but I consider the 
wording misleading. I would suggest to change it to something like 
trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable.

Moreover, I think merging section 2.1 with the text on client types in 
section 10 would make sense for the following reasons:
- there is large overlap between them
- It would introduce the term "native application" before it is used for 
the first time in Section 9

2.2. Registration Requirements

Why is the redirect URI a MUST? It should be a MUST for clients using 
the implicit grant and probably for "private" clients but why generally? 
I would suggest to change this to RECOMMENDED.

2.4 Client Authentication

"In addition, the client and authorization server establish a client
    authentication method suitable for the client type and security
    requirements of the authorization server."

Does this hold true for public clients?

2.4.1 Client Password

""

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 20 Jul 2011 22:58:57 +0200

2.1 Client types

Moreover, I think merging the text on client types in section 10 into 
section 2.1 would make sense for the following reasons:
- there is large overlap between them
- It would introduce the term "native application" before it is used for 
the first time in Section 9

2.4.1 Client Password

"Clients in possession of a client password MAY " Why not SHOULD?

regards,
Torsten.

Am 20.07.2011 22:56, schrieb Torsten Lodderstedt:
> clients. In my perception, the text just distinguishes clients which 
> can be authenticated and such which cannot. This is fine but I 
> consider the wording misleading. I would suggest to change it to 
> something like trusted/untrusted or authenticated/unauthenticated or 
> Verifiable/Forgeable.
>
> - It would introduce the term "native application" before it is used 
> for the first time in Section 9
>
> the implicit grant and probably for "private" clients but why 
> generally? I would suggest to change this to RECOMMENDED.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 22 Jul 2011 14:12:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Wednesday, July 20, 2011 1:59 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Issue 15, new client registration
> 
> 2.1 Client types
> 
> clients. In my perception, the text just distinguishes clients which can be
> authenticated and such which cannot. This is fine but I consider the wording
> misleading. I would suggest to change it to something like trusted/untrusted
> or authenticated/unauthenticated or Verifiable/Forgeable.

I'm open to changing the names.

I don't like trusted/untrusted because OAuth does not define trust. The authenticated/unauthenticated pair is also not ideal because the terms describe the outcome, not the nature of the client. As for verifiable/forgeable, I think these terms are too complicated for a casual reader.

My intention with public/private is to identify the nature of the client credentials. So a more verbose version would be 'public credentials/private credentials'. This also works with 'code' instead of 'credentials'.

It's clear from the past year of discussions that we need terminology to describe these two types.

Any other suggestions?

EHL

---

From: "Lu, Hui-Lan (Huilan)" <[email-masked]>
Date: Fri, 22 Jul 2011 16:33:53 -0500

Would "protected" and "open" work? Protected clients have protected credentials, while open clients don't. 

Huilan

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran
> Hammer-Lahav
> Sent: Friday, July 22, 2011 5:12 PM
> To: Torsten Lodderstedt; OAuth WG
> I don't like trusted/untrusted because OAuth does not define trust. The
> authenticated/unauthenticated pair is also not ideal because the terms describe the
> outcome, not the nature of the client. As for verifiable/forgeable, I think these terms
> are too complicated for a casual reader.
> 
> My intention with public/private is to identify the nature of the client credentials. So a
> more verbose version would be 'public credentials/private credentials'. This also
> works with 'code' instead of 'credentials'.
>

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 22 Jul 2011 23:46:29 +0200

Looks like Torsten already has capture my suggestion which is also what the Kiva documentation uses… Verifiable/Forgeable identity.  It's precise and avoids making a statement about trust, etc.

But only developers need such simple one-word classifications.  For end users (e.g., people w/ accounts who approve access for an app) we're be providing much more verbose explanations. For example. "This application's identity has ben verified… still (caution, caution, caution)"  or  "This application's identity cannot be verified. Only approve this application if you absolutely trust the application or link that sent you this page…"

App users can't discern the significance of public vs. private credentials.

To me, public credentials are not credentials at all. Yet another term to define. Better to be precise.

Another option (and terminology we use to help developers) Can Keep Secrets / Can't Keep Secrets.

Attached screenshots in case anyone is interested in how this plays out in real-world UI (vs. specs).

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 22 Jul 2011 14:49:34 -0700

In many cases you can verify a public client using a registered redirection URI.

EHL

From: Skylar Woodward [mailto:[email-masked]]
Sent: Friday, July 22, 2011 2:46 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client registration

Looks like Torsten already has capture my suggestion which is also what the Kiva documentation uses... Verifiable/Forgeable identity.  It's precise and avoids making a statement about trust, etc.

But only developers need such simple one-word classifications.  For end users (e.g., people w/ accounts who approve access for an app) we're be providing much more verbose explanations. For example. "This application's identity has ben verified... still (caution, caution, caution)"  or  "This application's identity cannot be verified. Only approve this application if you absolutely trust the application or link that sent you this page..."

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 1:59 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client registration

2.1 Client types

Any other suggestions?

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 23 Jul 2011 13:24:56 +0200

> In many cases you can verify a public client using a registered 

I'm in doubt regarding "many". This kind of verification makes the 
assumption that the evildoer uses a web application which requires a 
correct refering to his site.

I think client secrets (or other authentication schemes) are much more 
effective way of verifiying client identities.

Or let me put it the other way around. If redirect uri verification is 
sufficient in many cases. Why do we need a client secret?

regards,
Torsten.

> EHL
>
> *From:*Skylar Woodward [mailto:[email-masked]]
> *Sent:* Friday, July 22, 2011 2:46 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Torsten Lodderstedt; OAuth WG
> *Subject:* Re: [OAUTH-WG] Issue 15, new client registration
>
> Looks like Torsten already has capture my suggestion which is also 
> what the Kiva documentation uses... Verifiable/Forgeable identity. 
>  It's precise and avoids making a statement about trust, etc.
>
> But only developers need such simple one-word classifications.  For 
> end users (e.g., people w/ accounts who approve access for an app) 
> we're be providing much more verbose explanations. For example. "This 
> application's identity has ben verified... still (caution, caution, 
> caution)"  or  "This application's identity cannot be verified. Only 
> approve this application if you absolutely trust the application or 
> link that sent you this page..."
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]]
>     <mailto:[mailto:[email-masked]]> On Behalf
>
>     Of Torsten Lodderstedt
>
> I don't like trusted/untrusted because OAuth does not define trust. 
> The authenticated/unauthenticated pair is also not ideal because the 
> terms describe the outcome, not the nature of the client. As for 
> verifiable/forgeable, I think these terms are too complicated for a 
> casual reader.
>
> My intention with public/private is to identify the nature of the 
> client credentials. So a more verbose version would be 'public 
> credentials/private credentials'. This also works with 'code' instead 
> of 'credentials'.
>
> [email-masked] <mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 23 Jul 2011 09:38:16 -0700

Client authentication can be very useful for imposing restrictions on the token endpoint, as well as the reasons listed in 3.2.1.

Personally, given the clear direction the web is taking where applications are moving off hosted servers to mobile devices and in-browser software, I believe that focusing OAuth 2.0 ability to identify a client based on a secret is counterproductive. This is why my last rewrite put much more weight on the redirection URI and clarifying registration requirements.

OAuth 1.0 was highly criticized for failing to address client identity in public clients. I believe OAuth 2.0 offers a much better story, within the boundaries of what's possible today.

Back to the terminology question, we need to find terms that directly translate to the client ability to authenticate using credentials of other means. This is not about client identity or about trust.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Saturday, July 23, 2011 4:25 AM
To: Eran Hammer-Lahav
Cc: Skylar Woodward; OAuth WG
Subject: Re: [OAUTH-WG] Issue 15, new client registration

I'm in doubt regarding "many". This kind of verification makes the assumption that the evildoer uses a web application which requires a correct refering to his site.

I think client secrets (or other authentication schemes) are much more effective way of verifiying client identities.

Or let me put it the other way around. If redirect uri verification is sufficient in many cases. Why do we need a client secret?

regards,
Torsten.

EHL

-----Original Message-----

2.1 Client types

Any other suggestions?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 24 Jul 2011 23:45:44 -0700

How about confidential/open?

EHL

> Of Eran Hammer-Lahav
> Sent: Friday, July 22, 2011 2:12 PM
> authenticated/unauthenticated pair is also not ideal because the terms
> describe the outcome, not the nature of the client. As for
> verifiable/forgeable, I think these terms are too complicated for a casual
> reader.
> 
> My intention with public/private is to identify the nature of the client
> credentials. So a more verbose version would be 'public credentials/private
> credentials'. This also works with 'code' instead of 'credentials'.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 00:15:30 -0700

Thanks for the feedback.

> or authenticated/unauthenticated or Verifiable/Forgeable.

One alternative is confidential/open or confidential/public.
 
> Moreover, I think merging the text on client types in section 10 into section
> 2.1 would make sense for the following reasons:
> - It would introduce the term "native application" before it is used for the
> first time in Section 9

Done.
 
> Why is the redirect URI a MUST? It should be a MUST for clients using the
> implicit grant and probably for "private" clients but why generally?

It is a qualified MUST because you follow the reference. But I'll fix it to make it read better.

> Does this hold true for public clients?

New text:

          If the client type is private, the client and authorization server establish a client
          authentication method suitable for the security requirements of the authorization server.
          The authorization server MAY accept any form of client authentication meeting its
          security requirements.

          Private clients are typically issued (or establish) a set of client credentials used for
          authenticating with the authorization server (e.g. password, public/private key pair).

          The authorization server SHOULD NOT make assumptions about the client type or accept the
          type information provided without establishing trust with the client or its developer.
          The authorization server MAY establish a client authentication method with public
          clients. However, the authorization server MUST NOT rely on public client authentication
          for the purpose of identifying the client.

> "Clients in possession of a client password MAY " Why not SHOULD?

I rather never recommend Basic for anything... If the server supports DIGEST or better forms of password authentication, I don't want this text to imply Basic takes precedence.

EHL

---

From: Justin Richer <[email-masked]>
Date: Mon, 25 Jul 2011 10:40:31 -0400

I would avoid using the term "open" here as it has other deep-seated
meanings in the software world, particularly with regard to Open Source
and Open Standard stuff. FWIW, I think "confidential/public" or
"private/public" are serviceable.

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 08:54:58 -0700

I'll switch to confidential/public.

EHL

> From: Justin Richer [mailto:[email-masked]]
> Sent: Monday, July 25, 2011 7:41 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; Torsten Lodderstedt; OAuth WG
> meanings in the software world, particularly with regard to Open Source and
> Open Standard stuff. FWIW, I think "confidential/public" or "private/public"
> are serviceable.
> 
>  -- Justin
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Eran Hammer-Lahav
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf Of Torsten Lodderstedt
> > > > clients. In my perception, the text just distinguishes clients
> > > > which can be authenticated and such which cannot. This is fine but
> > > > I consider the wording misleading. I would suggest to change it to
> > > credentials/private credentials'. This also works with 'code' instead of
> 'credentials'.
> > >