XAuth critiques
John Panzer
jpanzer at google.com
Tue Jun 8 17:03:27 UTC 2010
On Tue, Jun 8, 2010 at 5:42 AM, Phillip Hallam-Baker <hallam at gmail.com>wrote:
> On Tue, Jun 8, 2010 at 4:19 AM, John Panzer <jpanzer at google.com> wrote:
> > On Mon, Jun 7, 2010 at 9:19 PM, Phillip Hallam-Baker <hallam at gmail.com>
> > wrote:
> >>
> >> As often happens in these debates, we have a proposal that has an
> >> acknowledged issue that we are being told isn't an issue because the
> >> developers don't see it as an issue.
> >>
> >
> > Actually, what's happening is that people are re-raising objections that
> > were discussed back in April and ignoring the answers that were given
> then.
> > It's fine to disagree with the answers, but it's polite to acknowledge
> that
> > answers have been given and, ideally, attempt to refute them instead of
> > pretending the answers don't exist.
>
> No, that is the exact answer I always get.
>
> And given my experience in national politics, including being one of
> the convention delegates who voted to found a major political party
> now in government in the UK, you are full of it.
> The claim 'this question has already been answered at a different
> time' is a classic tactic in agenda denial. When the politician is in
> office it is too soon to answer the awkward question, when they are no
> longer in office it would serve no purpose to look back at the past.
> There will never be a time to answer the question because the only
> possible answer is indefensible.
>
>
These questions were answered at the start of this thread. Here are the two
most useful links:
Chris Messina's original response in April:
http://googlecode.blogspot.com/2010/04/using-xauth-to-simplify-social-web.html?showComment=1271797199794#c3187792640589711632
My response to Eran's blog post:
http://www.abstractioneer.org/2010/06/xauth-is-lot-like-democracy.html
When you're having a technical discussion, it's usual and polite to raise
objections. When the objections are addressed, whether adequately or
inadequately, it's usual and polite to respond back in a semi-conversational
manner. E.g., "your response to objection #1 is insufficient because...".
Merely re-stating objection #1 more loudly does not help move the
discussion forward.
(Note: This thread has produced quite a bit of useful technical discussion
and I appreciate those who have engaged constructively.)
>
> >>
> >> I really take offense when I raise an issue and someone says 'that
> >> does not matter to anyone' or 'that issue has been dealt with'. The
> >> one issue that I have never found it difficult to get the industry to
> >> agree on is the necessity of ensuring that no party gains a
> >> proprietary leverage in a communication protocol.
> >
> > Please read the blog posts. It's very difficult to even discover what
> > different people consider to be "the problem". Shouting "privacy!"
> doesn't
> > actually move the discussion forward.
>
> Please read my book where I explain exactly what is wrong with your blog
> posts.
>
ISBN, please?
>
> This is another bogus form of argument called recourse to bogus
> authority. Instead of making the argument you claim that it is already
> won, a claim that is implicit in the notion that anyone who reads your
> blog posts will accept your argument.
>
I claim merely that I'm tired of repeating myself. It must be boring for
those following along too.
>
> You are defending your proposal in this forum, not your blog. If you
> can't provide a succinct exposition of your argument it is probably
> not a good one.
>
I've done this several times already, on this thread. But in order to be
succinct I would need to know what specific objections you have.
>
>
> There are three possible outcomes
>
> 1) Proposal is introduced and later modified to avoid lock-in
> 2) Proposal is introduced and proves impossible to modify once deployed
> 3) Proposal is rejected
>
> The problem with (1) is that my experience of HTTP is that it is
> almost impossible to change a scheme once deployed.
>
My proposal is that we freeze the protocol (the JS API) and allow the
implementation to be upgraded in the future.
>
> (3) is not the worst case outcome for most people. The best strategy
> for people who take lock in and control issues seriously is to attempt
> a veto before critical mass is achieved.
>
>
So your concern is lock in and control? What, specifically, are you
concerned about?
>
>
> --
> Website: http://hallambaker.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100608/3a2f04a6/attachment.html>
More information about the specs
mailing list