No subject

Fri Aug 15 23:49:43 UTC 2008

"openid.claimed_id" and "openid.identity" SHALL be either both present or b=
oth absent. If neither value is present, the assertion is not about an iden=
tifier, and will contain other information in its payload, using extensions=
 (Extensions).So you can't include one without the other.  And having neith=
er doesn't provide any authentication at all.

--_000_BFBC0F17A99938458360C863B716FE46397CC4F58Csimmbox01rapn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"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=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-family:"Calibri","sans-s=
erif";
color:#4F81BD'>More on this topic:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-family:"Calibri","sans-s=
erif";
color:#4F81BD'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-family:"Calibri","sans-s=
erif";
color:#4F81BD'>Though in our experiments where an OpenID2 OP fronted a SAML=
2 &nbsp;sp-initiator
entity requiring the IDP to use a persistent format (which passes a SAMl2&#=
8221;masked
identity cliam&#8221; through to the OpenID RP),I still considered the solu=
tion
consistent with the definition:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-family:"Verdana","sans-s=
erif";
color:black'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-family:"Verdana","sans-s=
erif";
color:black'>User-Supplied Identifier: <o:p></o:p></span></p>

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 t=
heir
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 Relyi=
ng
Party. <o:p></o:p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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 _selected_ the id claim value (a smartcard, and its
private signing-key); all the SAML2/OP gateway did was mask the value, usin=
g a
one-way function (that optionally received hashing-contributions from
attributes). The RP still has assurance, from protocol conformance, that th=
e
value is &#8211; unlike a local id &#8211; CONTROLLED by the user.<o:p></o:=
p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

The protocol design has to provide normative assurance that =
a conforming
(non-rogue) OP cannot spoof this &#8220;user control&#8221; signal. Otherwi=
se,
obviously, even a non-rogue OP is just a MITM point.<o:p></o:p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

Obviously determining which OP &nbsp;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 dire=
cted
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>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces at openid.net [mailto:general-bounces at 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=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'><br>
Resend, with intended addressing.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'><o:p>&nbsp;</o:p></span></p>

See
end. That claim is formally true, unless the extension is doing its own aut=
h. 
 
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, onc=
e
its learned (the hardway) to &quot;fallback&quot;. This design round, fallb=
ack
should be supported by an explicit security enforcing function crafted for =
the
fallback security control. 
 
One interesting &#8220;alternative&quot; extension &quot;doing auth&quot; w=
ould
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 entire=
ly
conforming claimedid url). <o:p></o:p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-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 cor=
e of
openid2 libraries bring: xrds metadata, https, discovery, dh associations (=
and
persistent sp-side state management for delegation), xri AND even xri trust=
ed
resolution (using saml tokens for communicating a namespace&#8217;s authori=
ty).<br>
<br>
.-----Original Message-----<br>
From: Andrew Arnott &lt;andrewarnott at gmail.com&gt;<br>
Sent: Friday, November 07, 2008 10:17 PM<br>
To: Breno de Medeiros &lt;breno at google.com&gt;<br>
Cc: OpenID List &lt;general at openid.net&gt;<br>
Subject: [LIKELY_SPAM]Re: [OpenID] Problems with delegation and directed
identity OPs<br>
<br>