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
Technical Summary
OpenID has found its usage on the Internet for Web Single Sign-On.
Simple Authentication and Security Layer (SASL, RFC 4422) and the
Generic Security Service Application Program Interface (GSS-API,
RFC 2743) are application frameworks to generalize authentication for
connection based protocols. This memo specifies a SASL and
GSS-API mechanism for OpenID that allows the integration of existing
OpenID Identity Providers with applications using SASL and GSS-API.
The OpenID foundation have assured the RFC editor that the
[OpenID] and [SREG] references are stable.
Working Group Summary
Nothing worth noting, this document was relatively non controversial
once the rough consensus was reached in the WG that using a browser
for some part of SASL authentication is acceptable for some deployments.
Document Quality
At least one implementation is in progress and one is planned.
Personnel
Alexey Melnikov is the document shepherd.
Stephen Farrell is the responsible AD.
RFC Editor Note
There are a bunch (7) of little changes.
First, in the References section:
1. Please add the following URL to the [OpenID] reference:
http://specs.openid.net/auth/2.0
OLD
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final",
December 2007.
NEW
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final",
December 2007. http://specs.openid.net/auth/2.0
2. Please add the following URL to the [SREG1.0] reference:
http://openid.net/sreg/1.0
OLD
[SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension
version 1.0", June 2006.
NEW
[SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension
version 1.0", June 2006. http://openid.net/sreg/1.0
3. Please move the [XRI2.0] reference from the normative (9.1) to
informative (9.2) references subsection.
4. In the security considerations text, section 6, please replace "[1]"
with "[OpenID]", apparently that's a bug in xml2rfc somehow
OLD
specification and to other literature [1]. Similarly, for general
NEW
specification and to other literature [OpenID]. Similarly, for general
5. In section 2.2:
OLD
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.
NEW
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, complex style-sheets,
etc. Because of this lack of structure, implementations will need to
invoke a rich browser in order to ensure that the
authentication can be completed.
6. On page 5, section 2, item 6:
OLD
6. The SASL client now sends an response consisting of "=", to
indicate that authentication continues via the normal OpenID
flow.
NEW
6. The SASL client now sends an response consisting of "=" to the
server, to indicate that authentication continues via the normal
OpenID flow.
7. On page 6, section 2, item 8:
OLD
Next the client optionally authenticates to the OP and then
approves or disapproves authentication to the Relying Party.
NEW
Next the end user optionally authenticates to the OP and then,
depending on the OP, may approve or disapprove authentication
to the Relying Party.