[OpenID] openid, foaf and attribute exchange

[Peter Williams]

Going back some while:

 

-----Original Message-----

> From: general-bounces at openid.net [mailto:general-bounces at openid.net]
On

> Behalf Of Mark Wahl

> Sent: Wednesday, July 25, 2007 6:16 AM

> To: Story Henry

> Cc: foaf-dev; general at openid.net

> Subject: Re: [OpenID] openid, foaf and attribute exchange

> 

> Story Henry wrote:

> 

> >    - duplicating effort. This spec is inventing a metadata format, a

> > query language and storage API, which is a lot of work. These things

> > have been done before:

> >       + metadata framework: as shown above RDF does this very well

> > already. It has a very powerful semantics, has gone through years of

> > review by some of the best thinkers in the world, is extensible,
self

> > describing, etc, etc... having to learn another special convention
as

> > proposed here, is one more unnecessary piece of work.

> 

> Actually there has not yet been defined a suitable protocol-

> indepdendent

> metadata format for identity schemas elements such as attribute types

> and claim types. "RDF" by itself is insufficient as there has not yet

> been defined ontologies for identity schemas.  To address this the

> Identity Commons Identity Schemas working group is defining a common

> set

> of metadata representation elements for OpenID (and CardSpace and

> others

> emerging protocols); a work-in-progress can be seen at

> http://idschemas.idcommons.net/moin.cgi/MetaData

> which can be expressed in RDF and retrieved via "GET", as described in

> http://idschemas.idcommons.net/moin.cgi/BasicRetrieval

> 

> 

> Mark Wahl

> Informed Control Inc.

> _______________________________________________

> general mailing list

> general at openid.net

> http://openid.net/mailman/listinfo/general

 

 

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).

 

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).

 

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.

 

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.

 

I don't see why one cannot simply rewrite such as the ACP 123
definitions (readable summary at 
http://www.isode.com/whitepapers/acp-133.html) 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.

 

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.

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070912/7b707c69/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 65600 bytes
Desc: image001.png
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070912/7b707c69/attachment-0002.png>