A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID
Note: This ballot was opened for revision 08 and is now closed.
(Stephen Farrell) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Russ Housley) No Objection
Comment (2011-11-29 for -)
(Pete Resnick) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) (was Discuss) No Objection
[DISCUSS issues addressed via correspondence.] There are several instances of "URL" instead of "URI"; is the difference meant to be significant?
(Robert Sparks) No Objection
(Sean Turner) (was Discuss) No Objection
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"?