[OpenID] AddId! - A useful idea of mine?!

Dick Hardt dick at sxip.com
Thu Feb 1 01:47:17 UTC 2007


Hi Lukas

The FOAF movement dissipated as the access control issue became  
understood. Ask Marc Canter.

Your example of a feed reader is potentially something that most  
people are ok exposing publicly, so that could work assuming the site  
is not wanting you to log in with OpenID, but is just using this as  
way to determine your feedreader.

But if you are supporting OpenID, then adding Attribute Exchange is  
pretty simple, and the user is not having to add the data to their  
Yadis file, it is just another attribute managed by the OP.  Of  
course the OP is likely writing out the Yadis file, so that can be  
optimized.  My preference would be to manage all my profile data in  
one place instead of having some in the yadis file, and some done  
with Attribute Exchange.

-- Dick

On 31-Jan-07, at 2:06 PM, Lukas Rosenstock wrote:

> This email includes all replies to Dmitry, Dick and Dan.
>
> Dmitry Shechtman wrote:
>> In my opinion, this is definitely worth working on. I believe the  
>> attached
>> specification draft still needs some polishing (why PDF BTW?).
>
> It's PDF because I wrote in in OpenOffice. And definetely it needs  
> some
> polishing, I am not an expert in both spec writing and the English
> language. This is only a first draft.
>
>> Since an XRD specifies multiple Services, it would seem more  
>> appropriate to
>> define a Service Type per Method ("Data Type" in your nomenclature).
>
> The idea behind this was to keep the XRD in small size. Compare these:
>
> <Service xmlns:ai=“http://addid.identity20.eu/ns“>
>   <Type>http://addid.identity20.eu/0.1d</Type>
>   <ai:supports>AddRSS AddATOM</ai:supports>
>   <URI>http://user.example.org/addid</URI>
> </Service>
>
> and
>
> <Service>
>   <Type>http://addid.identity20.eu/0.1d#AddRSS</Type>
>   <URI>http://user.example.org/addid</URI>
> </Service>
> <Service>
>   <Type>http://addid.identity20.eu/0.1d#AddATOM</Type>
>   <URI>http://user.example.org/addid</URI>
> </Service>
>
> Now imagine there are more than two data types.
>
> Dick Hardt wrote:
>> The approach presumes you want the services to be publicly available.
>
> Yes, that's right.
>
>> Another approach would be to use Attribute Exchange, so that when
>> logging into a site with OpenID, the site would ask for all the feed
>> mechanisms it understands, and you could release whichever mechanisms
>> you have that you would like to share with the site.
>
> Another approach, and not a bad one. Possibly more flexible and  
> secure.
> However, the idea behind my approach was to keep it _very_ simple and
> also decouple from OpenID.
>
> Dan Libby schrieb:
>> I am interested.  My first question is/was: How is this different
> from OpenID
>> attribute exchange?  After glancing through your spec, I could
> suggest an
>> answer, but I'd like to hear your thoughts.
>
> As I answered to Dick's comment, I wanted to decouple it from  
> OpenID in
> order to keep it very simple. Any site (I've called them DP, data
> provider) can ask for my OpenID (there are maybe even scenarios where
> OpenID is never involved), just do the Yadis protocol and find out for
> example if I have a feedreader and then construct the "Add my feed"  
> link
> for me. But maybe you thought of something else, not only using OpenID
> attribute exchange to find out what services I use but also do the
> actual data transfer through it, but that, in my opinion would add  
> even
> more complexity.
>
>> A few random thoughts/suggestions:
>>
>> 1) For contacts, why not include XFN relationship data if available?
>>
>> 2) For bookmarks, perhaps there is an existing bookmark file format
> we can
>> use?  Such as bookmarks.html used in mozilla.
>>
>> 3) What about foaf?  microformats?   too hard to parse?
>
> I try to comment on all this thought with an example: Imagine
> videntity.org supported AddIt/AddFriend. A videntity user now logs  
> onto
> LiveJournal with his OpenID. LJ parses the XRDS of the videntity user
> and provides me with a link, let's just call it
> http://videntity.org/addrelationship?url=http:// 
> thisuser.livejournal.com/.
> (Noticed something? Currently the parameter is called identity, if it
> was url videntity.org was already have an AddId-compatible DC). The  
> page
> I see lets me set the relationship values. It wouldn't make sense for
> "thisuser" to preset it, because I want to describe the relationship
> myself, don't I?
> Again, for bookmarks, we don't need anything more than url, because  
> all
> meta data can be retrieved from it.
> Back to the example, there could be another data type like AddFriend
> that allows me to add not an OpenID but a FOAF file to my social
> network. Again, the URL is enough. However it makes sense to use it  
> like
> above and then videntity.org fetches the FOAF file from thisuser and
> parses it.
> There is one use case for Microformats: A site is not a DP, but my
> browser / a plugin is. The plugin then could for example convert from
> hCard to vCard and build the link for me so that I can add this  
> vCard to
> my online address book.
>
>> 4) As this seems to be a fairly generalized framework for transfering
>> disparate formats, why not make it truly general and extensible,
> possibly via
>> mime types or xml namespaces...
>
> There is the namespace of AddId data types. For my first draft  
> there are
> seven of them and the list is extensible. However, since they are not
> URIs (which is again, to keep them short), the namespace is in control
> of the entity that "owns" the spec (which would be me, currently).
> Another possibility would be not to write a spec but only a design
> principle so that everyone could define their own Yadis Service Type.
> For the data formats, AddId is already built on standards. Either a  
> URL
> is given or a Base64-encoded data file, which is in well-known formats
> (like vCard/vCal).
>
> Regards,
>   Lukas
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>




More information about the general mailing list