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

Am 22.07.2011 23:49, schrieb Eran Hammer-Lahav:
>
> In many cases you can verify a public client using a registered 
> redirection URI.
>

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:skylar@kiva.org]
> *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..."
>
> 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).
>
> On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav wrote:
>
>
>
>
>
>
> -----Original Message-----
>
>     From: oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
>     [mailto:oauth-bounces@ietf.org]
>     <mailto:[mailto:oauth-bounces@ietf.org]> 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
>
>     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.
>
>
> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>