<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" 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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If two RPs each provisioned by a given OP each signal the
?arg=value to each other, then the value can act as half of the (unique, per
flow) entropy. The two RPs can then generate keying material, on the basis that
the OP is the ttp. In an n of m scheme for generating keying material from key
partisions, n parties in multicast group can similarly generate group keying
material.<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 simple pairwise keying is cheap and nasty version of WS-SX –
but it will essentially work. The two parties can then each perform the SSL
KDF, and setup the security contexts, one for each pipe between the RPs.<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'>IN this workd, openId auth (and its use of https, if any) is performing
the same role as certs/kerboeros/GSSAPI do in a particular ciphersuite used in
an SSL handshake.<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'>This is quite a cute architecture. https (and its PKI) provides
the control system over openid auth, which provides mutual authentication of
RPs by proxy, who can derive unique pariwise keying material, which creates confidential/integral
pipes between the RPs. Optionally, groupwise keying is shared between the OP
and n RPs, for use in AX update. N of M math can require that a certain minimum
number of RPs are party to the group.<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'><o:p> </o:p></span></p>
<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>Andrew
Arnott<br>
<b>Sent:</b> Monday, September 08, 2008 2:28 PM<br>
<b>To:</b> pnwtele@yahoo.com<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] http and https...again<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>I am very much in favor of OPs normalizing their
identifiers. <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'>But I daresay that if a user
adds ?a=1 to a user identifier, he's not your average joe-blow user and knows
exactly what he's doing. Nothing wrong with that. If the user wants
to splinter his identity by adding query args, he should be free to do so, just
as much as username/password doesn't prevent a user from creating to user
accounts. <o:p></o:p></p>
<div>
<p class=MsoNormal>On Mon, Sep 8, 2008 at 1:49 PM, Joe Tele <<a
href="mailto:pnwtele@yahoo.com">pnwtele@yahoo.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>Yes, it has nothing to do with fragments or recycling.
It has to do with inconsistencies with how OPs normalize (or not) their
user's claimed ids from user supplied indentifiers. Verisign does
nothing. These are types of things which could be argued as
"features" or "bugs" but in my opinion could result in user
base confusion (and RP confusion).<o:p></o:p></p>
<div>
<p class=MsoNormal><br>
<br>
--- On Mon, 9/8/08, SitG Admin <<a
href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>>
wrote:<br>
<br>
> From: SitG Admin <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>><br>
> Subject: Re: [OpenID] http and https...again<br>
> To: "Joe Tele" <<a href="mailto:pnwtele@yahoo.com">pnwtele@yahoo.com</a>><br>
> Cc: <a href="mailto:general@openid.net">general@openid.net</a><o:p></o:p></p>
</div>
<p class=MsoNormal>> Date: Monday, September 8, 2008, 1:38 PM<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal>> ><a
href="http://openid.net/pipermail/general/2008-September/005426.html"
target="_blank">http://openid.net/pipermail/general/2008-September/005426.html</a><br>
><br>
> I don't know about Verizon, but your reference to a<br>
> user typing in<br>
> this extra information is a clue that this doesn't have<br>
> to do with<br>
> generation fragments (distinguishing between successive<br>
> users with<br>
> the same URI). I'm thinking it's either a user<br>
> identification method<br>
> (such as Sun offers to assert "This is one of our<br>
> employees, but<br>
> we're not saying exactly who.") that tells the OP<br>
> (in this case,<br>
> Verizon) who the user is claiming to be (facilitating the<br>
> login flow)<br>
> without revealing anything meaningful about the user's<br>
> identity to<br>
> the RP, or something weird with how Verizon is resolving<br>
> claimed_id<br>
> (if the URI is different enough to not qualify as the same<br>
> user<br>
> anymore, you'd think Verizon's OP would detect that<br>
> and return an<br>
> error that the user did not exist).<br>
><br>
> Are you getting these "?a=1" variables appended<br>
> by real users, or are<br>
> they just showing up in tests? If the former, I'd<br>
> assume it to be<br>
> there for a reason; if the latter, I'd contact Verizon<br>
> about it.<br>
><br>
> -Shade<br>
<br>
<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><o:p></o:p></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>