The problem is that even if the Authorization Server only gives out
credentials to "trusted clients", those clients can be "hacked" and the
credentials compromised allowing for impersonation of the "trusted
client". Obviously, protecting the credentials is easier if the client
is a web server w
On 01/05/2012 08:37 AM, William Mills wrote:
It relies on the marketplace to do this. The current model is that apps are
not validated first, they are pulled if found to be hostile. You're making a
recommendation here about how an app marketplace should behave to be
trustworthy, and I think
It relies on the marketplace to do this. The current model is that apps are
not validated first, they are pulled if found to be hostile. You're making a
recommendation here about how an app marketplace should behave to be
trustworthy, and I think that's beyond the scope of users and client de
There's going to be a whole class of apps tat will be in violation of "Client
applications SHOULD avoid directly asking users for the their
credentials.". We know that already, because the password grant exists
and we have real use cases for it. I think we should strikes that
sentence and mov
On 01/05/2012 07:54 AM, Justin Richer wrote:
However, the contention about native apps that Mike brings up is misleading for
one key reason: if the user's browser is compromised (which is the attack
vector in question), then all OAuth-backed webapps will *also* be compromised,
since the bad p
I'm OK with the threat document including a line this this, or Eran's
proposed text, in the introduction to what OAuth can and can't do. It's
important to set scope appropriately. (and I am very sorry for that pun)
However, the contention about native apps that Mike brings up is
misleading for
The wording you propose is unacceptable. It is a rehash of the
same misleading nonsense that is in there now. In particular #1 and
#3 that say in effect "bad guys really should be good" are silly
and unhelpful. #2 has possibilities, but in its current form gives
absolutely no guidance as to what m
Why do you think this William? Apple does it? Google android market had to
pull 30 apps recently because they contained malware. There are automated
tools that will do some sanity checks on apps and it is only advice, i.e.
'could'
Mark
> William Mills
>
> " o Client applications could be val
Having read the suggested wording from Eran, William and Michael, I think
Eran's description is the most succinct and relevant: "OAuth does not
provide any protection against malicious applications and that the end user
is solely responsible for the trustworthiness of any native application
install
