+300 (if I can do that) to indicate my strong agreement. But if somehow
it is decided to add a few sentences on saying that OAuth cannot deal
with key-logging, I will insist on adding two sentences each on OAuth
being unable to deal with 1) earthquakes, 2) certain contageous
diseases, etc., and I will invite others to complete that list. And
encouraged by the precedent, I will require similar changes to TLS as
well as the whole list of password-authenticated key exchange protocols.
Melinda, in my reading the "temperature of the responses" is explained
by a huge amount of work achieved by this group, which involved many,
many real protocol issues on which it was hard to build the consensus.
Now that the consenus has been pretty much achieved, it is important to
complete OAuth 2.0, which means concentrating on real outstanding
issues--Barry has dutifully documented and enumerated them. I myself
got beaten up unjustly for pushing the use cases, but in order to
complete the protocol, I accepted the beating and agreed to wait until
the next rechartering. This is a matter of priorities. My opinion is
that we just cannot go off on a tangent to deal with something that is
not OAuth's concern. Because, if we do, someone will bring the
earthquakes, too.
Igor
On 9/6/2011 6:27 PM, Eran Hammer-Lahav wrote:
It is a problem. For a few months now we have been going through this over and
over again. The longer we work on this draft the more of this two-sentence
changes people suggest. They don't make the document any better, create a false
sense of comprehensiveness, and just further delay being done.
So yeah, unless you can prove that there is an actual problem, we are done.
EHL
On Sep 6, 2011, at 15:22, "Melinda Shore"<melinda.sh...@gmail.com> wrote:
On 09/06/2011 12:59 PM, John Kemp wrote:
The point is that you have a point.
He does, and that's in some large part why I don't
fully understand the temperature of the responses.
I do not think it's a particularly big deal to stick
a couple of sentences in the security considerations
underscoring the fact that OAUTH can't do anything
about a compromised host or a malicious application.
I've learned to live with the fact that sometimes
people implementing or deploying security technologies
don't fully understand them and it's my impression that
there's some number of people out there who think that
OAUTH and other third-party protocols provide sufficient
protection against password snagging.
Melinda
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
