<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><br>
Resend, with intended addressing.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>See
end. That claim is formally true, unless the extension is doing its own auth.<br>
<br>
Id vote for an openid 2.1 doing openid2 model of delegation more forcefully than
before (to prevent version conflicts, like TLS had/has to deal with). Perhaps
in an extension, let an openid2 RP interact with an openid1 OP, once its
learned (the hardway) to "fallback". This design round, fallback should
be supported by an explicit security enforcing function crafted for the
fallback security control.<br>
<br>
One interesting “alternative" extension "doing auth" would be
one that does the saml artifact resolver flow (over the extension, over the
openid association, given a saml url bearing the artifact value is a entirely
conforming claimedid url). <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>This
would also be a nice act of protocol convergence, where the back channel
security that saml2 artifact resolution requires would get all that the core of
openid2 libraries bring: xrds metadata, https, discovery, dh associations (and
persistent sp-side state management for delegation), xri AND even xri trusted
resolution (using saml tokens for communicating a namespace’s authority).<br>
<br>
.-----Original Message-----<br>
From: Andrew Arnott <andrewarnott@gmail.com><br>
Sent: Friday, November 07, 2008 10:17 PM<br>
To: Breno de Medeiros <breno@google.com><br>
Cc: OpenID List <general@openid.net><br>
Subject: [LIKELY_SPAM]Re: [OpenID] Problems with delegation and directed
identity OPs<br>
<br>
>From the spec:<br>
Value: (optional) The Claimed Identifier.<br>
"openid.claimed_id" and "openid.identity" SHALL be either
both present or both absent. If neither value is present, the assertion is not
about an identifier, and will contain other information in its payload, using
extensions (Extensions).So you can't include one without the other. And
having neither doesn't provide any authentication at all. </span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
</div>
</body>
</html>