Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-07.txt

From: [email-masked]
Date: Wed, 23 Nov 2011 06:12:50 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

	Title           : A SASL & GSS-API Mechanism for OpenID
	Author(s)       : Eliot Lear
                          Hannes Tschofenig
                          Henry Mauldin
                          Simon Josefsson
	Filename        : draft-ietf-kitten-sasl-openid-07.txt
	Pages           : 23
	Date            : 2011-11-23

   OpenID has found its usage on the Internet for Web Single Sign-On.
   Simple Authentication and Security Layer (SASL) and the Generic
   Security Service Application Program Interface (GSS-API) are
   application frameworks to generalize authentication.  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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-07.txt

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Nov 2011 15:18:23 +0100

Hi,

This version addresses the following issues that were raised in various
reviews, as discussed in Taipei:

  * Reference instead of copy OpenID specification;
  * Replace URIs for OpenID spec, as requested by OpenID foundation
  * Add explanation for transaction ID
  * Use HTTPS
  * Update references (3920->6120)
  * XRIs MUST NOT be used
  * Tighten security considerations.

Eliot

On 11/23/11 3:12 PM, [email-masked] wrote:
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: William Mills <[email-masked]>
Date: Mon, 28 Nov 2011 17:49:40 -0800 (PST)

I've been asked to be a reviewer for this.  My most profound question here is around the choice to make the identity assertion by the OP to the RP out of band.  This is a really significant choice as it puts a huge design issue in the hands of the implementer, that the RP has to provide an HTTP entrypoint which implicitly has some form of RPC with the SASL enabled server to communicate the identity authenticated for a session.  Why was this choice made in favor of having the return form the OP presented in-band as a SASL client message?  

It seems like the choice is to minimize the impact on the client so that a browser user agent can be used for the client interaction with the OP.

Thanks,

-bill