<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:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.5pt;
        font-family:Consolas;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:Consolas;}
.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=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText style='margin-left:.5in'>http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>When the user logs into such an
OpenId provider using foaf+ssl, the OP<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>having fetched the foaf file to
verify identity, find the openid in<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>that graph, then gets the openid
page and verifies that it points to<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>the foaf file as well as to the
OP.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><span style='color:black'>Now that’s cute, because the
second half is really only a minor variation of what OPs and RPs do today
(using HTML metatags and XRD.SEP.localids for cross-domain name mapping). It
goes a bit further in the first half, as it also address user auth (by
providing a basis for accepting the SSL layers of assertion of uncertified public
key as one that actually binds to a webid, that implies an openid, which an OP
may now release to the RP as a claimed identifier). (*)<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>But also note how different it
was in application to my conception. I had the foaf+ssl talking to the RP rather
than the OP (where the RP which would do all the various mappings, resolvings,
and verifying). I shifted the control point (back the way it was in the openid1
world), turning the OP into just one of several transitory intermediaries on
the message relay path that separates me the RP from you the user.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>Now the nice thing is, that I
think both controls models work; and neither excludes the other. Either RP or
OP can be applying this sort of thing, or BOTH can. Thus, we address the
balance of power issue, addressing the issue of dependency becomes a barrier to
adoption. One gets around the confidence problem of dependency, because as an
RP one now has built in resilience to failure, and the expectation that of
course the RP can ALSO challenge the user directly (using its own run of
foaf+ssl).<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>Peter.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>(*) rather than have a
third-party sign the foaf file, I’d still like the ssl layer (at RP) to be
verifing the digest of the foaf file referenced by the webid (where the hash is
in some of other field of the client cert, tied to that foaf file). In this
way, the whole system is one of essentially one of an ssl-based, self-assertion
of an authenticated foaf file to the RP (making things akin to a self-asserted
infocard).<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
</div>
</body>
</html>