Re: [Gen-art] Gen-ART LC review of draft-ietf-kitten-sasl-openid-06.txt

Eliot Lear <> Fri, 04 November 2011 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AD4D21F8B1A for <>; Fri, 4 Nov 2011 03:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -108.264
X-Spam-Status: No, score=-108.264 tagged_above=-999 required=5 tests=[AWL=-1.665, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TGFX75t2JHnz for <>; Fri, 4 Nov 2011 03:28:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1401E21F8B17 for <>; Fri, 4 Nov 2011 03:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2873; q=dns/txt; s=iport; t=1320402487; x=1321612087; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QEXfgs+hD/VhvRaFzJPCn/FnkjcKOVZZKU5RhqGeuOI=; b=S27/5g4JhSH4bHb1PrzNL7XhJCYLroJ6XcM50AwM+pqWAnxxetsDkbiz YsZr81XivErmj4MlsYXied5W/9b2d/Vj8zMPbv5hgji47VtEhbkd6Ugzb UCzDAkJNVEUuEe7ux7EpiQzsFQlOm8FFMK/Qe0zOsokMVC3NwQVBa3qou k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.69,455,1315180800"; d="scan'208";a="2412456"
Received: from ([]) by with ESMTP; 04 Nov 2011 10:28:06 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id pA4AS54q017456; Fri, 4 Nov 2011 10:28:05 GMT
Message-ID: <>
Date: Fri, 04 Nov 2011 11:28:06 +0100
From: Eliot Lear <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Brian E Carpenter <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <>,
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-kitten-sasl-openid-06.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Nov 2011 10:28:08 -0000

Hi Brian,

Apologies for the belated review.  Please see comments below.

On 7/22/64 8:33 PM, Brian E Carpenter wrote:
> Please see attached review.

> "some sort of..."   "any number of ways" This is very loose language
> for a standards-track draft. I don't know what to suggest but it
> just seems too vague as it is. If all you can actually specify is
> a transport mechanism, then shouldn't the specification avoid hand-waving
> on other matters?

The issue is that OpenID was designed where you could serialize with
cookies.  You can't do that with a non-browser app in the middle. 
Still, the matter is internal to the RP.  There is no need for the
information to be interpreted by other parties, and as such we ought not
specify its form.  If you would like I can add some text around this
since it seems to be a point of confusion.

> > 2.2.  Discussion
> >
> >    As mentioned above OpenID is primarily designed to interact with web-
> >    based applications.  Portions of the authentication stream are only
> >    defined in the crudest sense.  That is, when one is prompted to
> >    approve or disapprove an authentication, anything that one might find
> >    on a browser is allowed, including JavaScript, fancy style-sheets,
> >    etc.  Because of this lack of structure, implementations will need to
> >    invoke a fairly rich browser in order to ensure that the
> >    authentication can be completed.
> Errm what? "Fairly rich" is a useless statement from a specification PoV.
> And in any case, Section 2 is "Applicability for non-HTTP Use Cases",
> so I don't understand what JS, style-sheets or browsers have to do
> with it.

The whole point of this mechanism is for non-browser apps to leverage
browsers for their authentication.  Note that you are quoting
"discussion", and that any implementer would understand the context of
what that means (especially given the previous sentence).

> The second sentence seems to be missing a noun after "astute". But more
> profoundly, this paragraph really isn't OK for a technical specification.
> It mixes up a vague explanation of server behaviour with an imprecise
> discussion of a solution not adopted. Could the paragraph be rewritten
> in a style that will help an implementor write code? Is it saying that
> on receipt of an "=" response the server should continue to wait?

We fixed the nit.  However, your profound comment is directed at
"Discussion".  A precise normative specification  as well as an example
follows below the above text.

> Why is kitten-sasl-openid
> on the standards track when it depends on a document that clearly
> could have
> been proposed as standards track but wasn't?

No attempt is made here to "back door" standardize OpenID, but rather to
simply make it available to SASL applications.