<HTML><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText36457 dir=ltr>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>If we finally have a motivating use case... I judge that the topic is simply not addressed in the openid standard. Stuff about "RP remembering" is just not part of the use case analysis OR the protocol design. Its for RP sites to address this topic (just a like a million other signup/signon screens already do), probably using cookies. If the RP sites wants to to rely on HTTP redirect signals, thats fine too: but its a "local issue".</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>(I assume below "OpenID agent" means OpenID consumer (RP), and find the "delegation server" means finds the host serving the user's discovery information (containing the openid metadata))</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>"I think you have misunderstood my problem though. When the OpenID agent follows<BR>this redirect to the new location and finds the delegation server, processes the<BR>login and what have you, I am saying that when it remembers your OpenID for<BR>future uses or for display on a website it should use the original URI and not<BR>the one that was found by redirection."<BR><BR>----------</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Now let me switch sides.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Having shown openid recently to folks in my profession, who are used to the SAML's IDP-initiated workflow and its associated ease of use, we do have an issue. If our realtor portal connects folks to 10 SP at the beginning of the workday, we cannot have the user having to type in 10 openids at signon screens, all with different pracices concerning "remembering".</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Either we standardzied better unsolicited auth and make it interoperable (in practice, which its not), or we address DO NOW ADMIT some of the use cases that Noah is properly addressing.</DIV></DIV></BODY></HTML>