<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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<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: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;}
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.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
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 92.4pt 1.0in 92.4pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</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>Going back some while:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>-----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>> From: general-bounces@openid.net
[mailto:general-bounces@openid.net] On<o:p></o:p></p>
<p class=MsoPlainText>> Behalf Of Mark Wahl<o:p></o:p></p>
<p class=MsoPlainText>> Sent: Wednesday, July 25, 2007 6:16 AM<o:p></o:p></p>
<p class=MsoPlainText>> To: Story Henry<o:p></o:p></p>
<p class=MsoPlainText>> Cc: foaf-dev; general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>> Subject: Re: [OpenID] openid, foaf and attribute exchange<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Story Henry wrote:<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> > - duplicating effort. This
spec is inventing a metadata format, a<o:p></o:p></p>
<p class=MsoPlainText>> > query language and storage API, which is a lot
of work. These things<o:p></o:p></p>
<p class=MsoPlainText>> > have been done before:<o:p></o:p></p>
<p class=MsoPlainText>> > + metadata
framework: as shown above RDF does this very well<o:p></o:p></p>
<p class=MsoPlainText>> > already. It has a very powerful semantics, has
gone through years of<o:p></o:p></p>
<p class=MsoPlainText>> > review by some of the best thinkers in the
world, is extensible, self<o:p></o:p></p>
<p class=MsoPlainText>> > describing, etc, etc... having to learn another
special convention as<o:p></o:p></p>
<p class=MsoPlainText>> > proposed here, is one more unnecessary piece of
work.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Actually there has not yet been defined a suitable
protocol-<o:p></o:p></p>
<p class=MsoPlainText>> indepdendent<o:p></o:p></p>
<p class=MsoPlainText>> metadata format for identity schemas elements such
as attribute types<o:p></o:p></p>
<p class=MsoPlainText>> and claim types. "RDF" by itself is
insufficient as there has not yet<o:p></o:p></p>
<p class=MsoPlainText>> been defined ontologies for identity schemas.
To address this the<o:p></o:p></p>
<p class=MsoPlainText>> Identity Commons Identity Schemas working group is
defining a common<o:p></o:p></p>
<p class=MsoPlainText>> set<o:p></o:p></p>
<p class=MsoPlainText>> of metadata representation elements for OpenID (and
CardSpace and<o:p></o:p></p>
<p class=MsoPlainText>> others<o:p></o:p></p>
<p class=MsoPlainText>> emerging protocols); a work-in-progress can be seen
at<o:p></o:p></p>
<p class=MsoPlainText>> http://idschemas.idcommons.net/moin.cgi/MetaData<o:p></o:p></p>
<p class=MsoPlainText>> which can be expressed in RDF and retrieved via
"GET", as described in<o:p></o:p></p>
<p class=MsoPlainText>> http://idschemas.idcommons.net/moin.cgi/BasicRetrieval<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Mark Wahl<o:p></o:p></p>
<p class=MsoPlainText>> Informed Control Inc.<o:p></o:p></p>
<p class=MsoPlainText>> _______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>> general mailing list<o:p></o:p></p>
<p class=MsoPlainText>> general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>> http://openid.net/mailman/listinfo/general<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Looking at henry’s card using an explorer that
understands and presents both the typelib schemas and associated instances for
the classes conforming the several types, I don’t really see why the
above is true. (This tool is almost identical to tools we used at least a decade
ago, making it easy to see why what we knew 10 years ago holds today).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I fail to see why the Person class in FOAF should not
play the same role that the organizationalPerson or eduPerson (say) played in Secure
Directory work based on the X.500 standards (1992).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Similarly, I fail to see why the seeAlso relation is any
different to a similar entry in an LDAP white pages directory entry referencing
a yellow page entry. Similarly such as the ACP alias seem to be properly modeled.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Given the recognition that RDF (and thus FOAF) has the constructs
of distinguished attributes (critically necessarily for the semantic model) and
the ability to serialize query results in a standard canonical serialization format
that can be signed/encrypted, we seem to have all that one needs to when one
leverages OpenID AX and extensions to assert well defined, and distinguished identity
claims in the midst of a strong authentication protocol.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I don’t see why one cannot simply rewrite such as the
ACP 123 definitions (readable summary at <a
href="http://www.isode.com/whitepapers/acp-133.html">http://www.isode.com/whitepapers/acp-133.html</a>)
using the modern notation of N3triples. The ontology of identity attributes derived
from the distinguished attributes of object instances become assertable claims –
which a suitable profile of a FOAF_enhanced OpenID Auth 2.0 (with extensions
and AX) protocol can properly signal.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Now, this isn’t to deny that the SemWeb+OpenID can
go much further that the directory information model + directory access
and chaining services of X.500 standards world. The sembweb’s meta-directory
features (inferences based on SubProperty inferences) seem to go much further
than subattributes and sub-objectclasses went in the X.500 world, allowing a
query expressed in one schema to be resolved against objects marked up in a
variety of domain-specific schemas. Furthermore, the integration with SPARQL and
the SPARQL protocol clearly allows a much wider range of domain-specific querying
models to be defined and communicated – a feature that is not obviously present
in the older X.500 directory architecture.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><img border=0 width=1277 height=432 id="Picture_x0020_1"
src="cid:image001.png@01C7F52D.E9099040"><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
</div>
</body>
</html>