<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: "Editors" Conference Call</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=828182706-31102006><FONT face=Arial
color=#0000ff size=2>I'll let Dick explain since it was his proposal and I
didn't really care about if we changed the name or not. ;)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=828182706-31102006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=828182706-31102006><FONT face=Arial
color=#0000ff size=2>--David</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Patrick Harding
[mailto:pharding@pingidentity.com] <BR><B>Sent:</B> Monday, October 30, 2006
7:47 PM<BR><B>To:</B> Recordon, David; specs@openid.net<BR><B>Subject:</B> RE:
"Editors" Conference Call<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>Dave,<BR>Can you please clarify how an OpenID Provider is 'very'
different from the role of Identity Provider as defined in SAML or
WS-*.<BR>Thanks<BR>- Patrick<BR><BR>> Rename "Identity Provider" to "OpenID
Provider" (IdP -> OP) to add<BR>clarity to the term since IdP has a very
different meaning in the SAML<BR>and WS-*
worlds<BR><BR><BR><BR><BR>-----Original Message-----<BR>From:
specs-bounces@openid.net on behalf of Recordon, David<BR>Sent: Mon 10/30/2006
7:51 PM<BR>To: specs@openid.net<BR>Subject: "Editors" Conference
Call<BR><BR>This morning Dick, Josh, and I got on Skype for 2.5 hours to try
and<BR>hash through all the remaining proposals. Unfortunately Brad
couldn't<BR>join us, though I did talk to him about some of this stuff as
well<BR>beforehand.<BR><BR> - Authentication Age will be developed as an
extension due to questions<BR>around what is the best way for it to work, what
features does it need,<BR>etc<BR><BR> - The field "setup_url" will be
removed from a checkid_immediate<BR>response, rather the RP should fallback to a
checkid_setup request to<BR>complete the transaction. It has been found
that in the, albeit few,<BR>implementations of checkid_immediate this is the
behavior for the<BR>setup_url anyway.<BR><BR> - Support bare requests by
having the field "openid.return_to" as<BR>optional in checkid_* requests.
There is a worry of user's not knowing<BR>when they'll be redirected back and
when they won't, though that will<BR>only be worked out by allowing this
functionality.<BR><BR> - Clarify that the openid.realm parameter should be
used to uniquely<BR>identifier relying parties<BR><BR> - There are some
places where it could be clear in step-by-step<BR>instructions of what an IdP
needs to do in various parts of the<BR>protocol, like is done in section 12 for
rp's. Sxip will provide<BR>pointers to where this clarity can be
added.<BR><BR> - Rename "Identity Provider" to "OpenID Provider" (IdP ->
OP) to add<BR>clarity to the term since IdP has a very different meaning in the
SAML<BR>and WS-* worlds<BR><BR> - The spec won't speak to what a RP should
do if it has an identifier<BR>like "user@example.com", worried about setting a
confusing precedent of<BR>allowing this form of identifier for discovery.
Users are used to<BR>entering, "example.com" in their URL bar to goto the site,
so entering<BR>the same to login doesn't seem like to far of a stretch.
All of OpenID<BR>has a user education challenge and this doesn't seem very
different.<BR><BR> - Spec will say in essence, "RP's SHOULD give the text
field a user<BR>enters their OpenID Identifier a name attribute with a value
of<BR>'openid_identifier', though if a RP wishes to support rich clients
it<BR>MUST do so".<BR><BR> - Dick will be writing a separate document
discussing how RPs can<BR>advertise services, logos, etc<BR><BR> - There
cannot be parameters with the same name, make sure spec says<BR>this, we think
it does.<BR><BR> - Josh will be updating his delegation proposal patch to
specify two<BR>identifiers for all transactions. This will create a
consistent<BR>paradigm when dealing with delegation or when not.<BR><BR>Goal is
to have all of these changes made by end of day Wednesday. I<BR>doubt I've
added enough detail in all places, so feel free to ask for<BR>clarifications or
wait to comment on the next
draft.<BR><BR>--David<BR>_______________________________________________<BR>specs
mailing list<BR>specs@openid.net<BR><A
href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR><BR></FONT></P></BODY></HTML>