A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID
draft-ietf-kitten-sasl-openid-08

[DISCUSS issues addressed via correspondence.]

There are several instances of "URL" instead of "URI"; is the difference meant to be significant?

  The Gen-ART Review by Brian Carpenter on 24-Nov-2011 includes a
  request for better clarity.  Please consider this comment.

  > 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.

  This language remains rather loose. At least, I believe, "fancy" and 
  "fairly rich" need to be replaced by more specific terms such as
  "complex" and "sufficiently powerful" respectively. I think there may
  be interoperability issues hidden here in any case, but that is
  probably inevitable.

1) It would be nice if the Figure showed that the RP is the SASL server. You use RP and SASL server and you use client and SASL client and it would be really nice if you just picked one set of terms and used it consistently in the steps in s2. For a split second step 1 made me ponder whether a fourth box was needed in the Figure.

2) It would be nice if it said to whom the response is sent in the following:

6. The SASL client now sends an response consisting of "=", to indicate that authentication continues via the normal OpenID flow.

3) In the following I assume it's the OP who approves/disapproves the authentication:

8. Next the client optionally authenticates to the OP and then
approves or disapproves authentication to the Relying Party.

so maybe:

8. Next the client optionally authenticates to the OP and then
the OP approves or disapproves authentication to the Relying
Party.

4) Instead of should be expected to respond in the following:

10. The RP MAY send an OpenID check_authentication request directly
to the OP, if no association has been established, and the OP
should be expected to respond.

maybe just: "should respond"?