<HTML><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText3954 dir=ltr>
<DIV dir=ltr><FONT color=#000000>slightly offtopic, but related enough to address the core issue. </FONT></DIV>
<DIV dir=ltr><FONT color=#000000></FONT> </DIV>
<DIV dir=ltr><FONT color=#000000>From what Sxip folks tought me, the claimed ID asserted by the OP can have any form, when ASSERTED.</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>SO, I had my consumer interpret the URL that is an openid, claimed. It redirects to the URL in a querystring parameter.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>That is, Im doing consumer proxying (via this 'querystring "as a redirect" intepretation'). It allows one to now logon to a downstream consumer that is an openid->saml gateway, which auto-follows the OP's redirect/ion in the claimedID to invoke the assertion of a SAML1 or SAML2 assertion to a SAML-only RP site (the user's ultimate destination).</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I think my goal for today is to deploy this, so my openid gateway's consumer can be a redirect-portal to access Google Apps (a SAML only site, to date). Login to the consumer gateway via openid to auto-logon (via SAML) to Google Apps. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Plaxo can do the same....by recognizing the form of the Cliamed ID from certain OP Identifiers, and invoking the same gatewaying server. Whether the gateway server atually relays or not will depend on its "evaluation" of Plaxo - as a trustworthy business, etc, and the knowledge of the trust graph between Goole and Plaxo.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>With this proxying model done in both directions, the gateways become the trusted relays that enforce the assurance metrics, rather than end systems using PKI and untrustworthy http or https discovery, etc. Nothing in the model really requires that it be a SAML/openid gateway. Its could be a openid/openid gateway, for all its matters.</DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Peter Williams<BR><B>Sent:</B> Tue 3/4/2008 10:49 AM<BR><B>To:</B> Noah Slater<BR><B>Cc:</B> general@openid.net<BR><B>Subject:</B> RE: [OpenID] Problems with OpenID and TAG httpRange-14<BR></FONT><BR></DIV>
<DIV>
<DIV id=idOWAReplyText9745 dir=ltr>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr><FONT color=#000000 size=2>"URL Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of <A class=info href="http://openid.net/specs/openid-authentication-2_0.html#RFC3986" target=_blank><STRONG><FONT color=#990000>[RFC3986]<SPAN> (</SPAN><SPAN class=info>Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</SPAN><SPAN>)</SPAN></FONT></STRONG></A> to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when <A class=info href="http://openid.net/specs/openid-authentication-2_0.html#requesting_authentication" target=_blank><STRONG><FONT color=#990000>requesting authentication<SPAN> (</SPAN><SPAN class=info>Requesting Authentication</SPAN><SPAN>)</SPAN></FONT></STRONG></A>. "</FONT></DIV></BLOCKQUOTE>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Hmm. I tend to agree with you: its that term "final destination URL". </FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>I think a "final URL" is a "final destination URL" that has been normalized using 3986. The final URL is of course a function of the URL Identifier, and gets cast as a Claimed Identifier.</FONT></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV></DIV></DIV></BODY></HTML>