<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;}
@font-face
{font-family:Verdana;
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.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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 lang=EN style='font-family:"Calibri","sans-serif";
color:#4F81BD'>More on this topic:<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN style='font-family:"Calibri","sans-serif";
color:#4F81BD'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN style='font-family:"Calibri","sans-serif";
color:#4F81BD'>Though in our experiments where an OpenID2 OP fronted a SAML2 sp-initiator
entity requiring the IDP to use a persistent format (which passes a SAMl2”masked
identity cliam” through to the OpenID RP),I still considered the solution
consistent with the definition:<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'>User-Supplied Identifier: <o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:96.0pt'><span lang=EN style='font-family:
"Verdana","sans-serif";color:black'>An Identifier that was presented by the end
user to the Relying Party, or selected by the user at the OpenID Provider.
During the initiation phase of the protocol, an end user may enter either their
own Identifier or an OP Identifier. If an OP Identifier is used, the OP may
then assist the end user in selecting an Identifier to share with the Relying
Party. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The definition requires that the OP assist the _user__select
what id to share with the RP. That is the OP has no say, and cannot invent
identifiers, during directed identity flow. In our experiment, the user had conformingly
and positively _<i>selected</i>_ the id claim value (a smartcard, and its
private signing-key); all the SAML2/OP gateway did was mask the value, using a
one-way function (that optionally received hashing-contributions from
attributes). The RP still has assurance, from protocol conformance, that the
value is – unlike a local id – CONTROLLED by the user.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The protocol design has to provide normative assurance that a conforming
(non-rogue) OP cannot spoof this “user control” signal. Otherwise,
obviously, even a non-rogue OP is just a MITM point.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Obviously determining which OP is rogue and non rogue lies
outside of OpenID specs. RPs may rely on xmldsigs in the discovery response to
validate the authority and/or trustworthiness of a given OP to perform directed
identity at a given endpoint. The authority comes from the structure of the
XRDS bindings (of protocol endpoint to assertion namespace), and the
trustworthiness signal comes classically from the cert chain supporting the
xmldsig.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Peter
Williams<br>
<b>Sent:</b> Saturday, November 08, 2008 2:29 PM<br>
<b>Cc:</b> OpenID List<br>
<b>Subject:</b> [LIKELY_SPAM]Re: [OpenID] [LIKELY_SPAM]Re: Problems with
delegation and directed identity OPs<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<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>