<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: "Editors" Conference Call</TITLE>
</HEAD>
<BODY>
<!-- 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>