[OpenID] openid, foaf and attribute exchange

[Dick Hardt]

AX can easily move structured and signed data -- we have an example at

	https://verify.sxip.com/email/

If you are using Sxipper as your OP

-- Dick

On 30-Jul-07, at 11:19 AM, Recordon, David wrote:

> I can see it depending a lot on what you're doing with OpenID and what
> data you're moving around.  I wouldn't outright write off using the AX
> mechanism to exchange structured data. :)
>
> --David
>
> -----Original Message-----
> From: Dick Hardt [mailto:dick at sxip.com]
> Sent: Monday, July 30, 2007 11:17 AM
> To: Recordon, David
> Cc: Story Henry; general at openid.net; foaf-dev
> Subject: Re: [OpenID] openid, foaf and attribute exchange
>
> Moving the random, temporary location of a FOAF file does make sense
> with AX.
>
> The FOAF crowd was pretty discouraged when it became clear that a  
> public
> FOAF file was NOT something most people would want heavily populated
> with data.
>
> -- Dick
>
> On 30-Jul-07, at 11:04 AM, Recordon, David wrote:
>
>> One thing to think about is that the Attribute Exchange spec could be
>> used to do nothing more than move around a FOAF file, vCard, etc as
>> one of the attributes.
>>
>> Great feedback though.
>>
>> Thanks,
>> --David
>>
>> -----Original Message-----
>> From: general-bounces at openid.net [mailto:general- bounces at openid.net]
>> On Behalf Of Story Henry
>> Sent: Wednesday, July 25, 2007 3:06 AM
>> To: general at openid.net
>> Cc: foaf-dev
>> Subject: [OpenID] openid, foaf and attribute exchange
>>
>> In my post "foaf and openid" [1] Mathew asked:
>>
>> "Is there a way to get this information just in the normal course of
>> things through Attributes in the OpenID spec?"
>>
>> I read up about attribute exchange and responded this:
>>
>> I searched the openid site and found the Openid attribute exchange
>> draft, which describes a proposed way to do this by querying the
>> Identity Provider (https://openid.sun.com/openid/service in my
>> example) for attributes. It also defines a method for storing
>> attributes there.
>> I see three problems with this:
>>
>>    - It ties the identity provider to the identity. The nice thing
>> about OpenId, is that it separates the role of the identity provider
>> and the identity. This allows one to have an id (I could use http://
>> bblfish.net/) and change identity provider over time, as I change job
>> for example, or even have a number of different ones at the same  
>> time.
>> The OpenId attribute exchange is overloading the identity provider
>> (which is really an identity verifier) functionality relating to
>> identity description.
>>    - It does not feel RESTful. If something is to return information
>> it should have a URL. Here there is very clearly overlapping of
>> concerns as explained above. What is the url for information for one
>> identity here?
>> I have a large alarm bell ringing when I read sections such as:  
>> "Fetch
>
>> message" and "store message". Is that not the equivalent of HTTP GET
>> and PUT?
>>    - 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.
>>       + query language: SPARQL though not yet finished does  
>> everything
>
>> that is needed here as shown in the example above
>>       + storage: this could be done using a number of well known
>> technologies, such as ftp, scp, Atom Protocol, or even WebDav.
>> AtomP and
>> WebDav are even nicely RESTful.
>>
>> A simple link to a foaf file as described in this article covers most
>> uses cases, and is incredibly flexible. If one wants to have  
>> different
>
>> personas, one should probably use different openids anyway, since as
>> the foaf people have correctly defined it foaf:openid is an inverse
>> functional property. So if someone knows that
>>
>> _:niceJoe a foaf:Person;
>>           foaf:openid <http://joe.openid.eg/>;
>>           foaf:nick "joey";
>>           foaf:email <mailto:nicejoe at love.eg> .
>>
>> and also knows that
>>
>> _:badJoe a foaf:Person;
>>           foaf:openid <http://joe.openid.eg/>;
>>           foaf:nick "bj";
>>           foaf:email <mailto:badjoe at bondage.eg> .
>>
>> Then they know that
>>
>> [] a foaf:Person;
>>           foaf:openid <http://joe.openid.eg/>;
>>           foaf:nick "joey";
>>           foaf:nick "bj";
>>           foaf:email <mailto:nicejoe at love.eg> ;
>>           foaf:email <mailto:badjoe at bondage.eg> .
>>
>> An open id identifier is an identifier. You should really not be  
>> using
>
>> the same identifier if you want to have different independent
>> personas.
>>
>> Henry
>>
>> [1] http://blogs.sun.com/bblfish/entry/foaf_openid
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>
>