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

Dick Hardt dick at sxip.com
Thu Feb 1 07:19:50 UTC 2007

All of these formats are limiting Chris. InfoCards and OpenID  
Attribute Exchange propose using a URI for each attribute. This  
allows the world to add new attributes without having to have the  
schema centrally managed. There is consensus building for this model  
(including the Higgins people) over at:

Idschemas mailing list
Idschemas at idcommons.net

On 31-Jan-07, at 11:11 PM, Chris Messina wrote:

> I strongly advocate for using XOXO, xFolk, hcard and XFN here.
> We've had a lot of conversations about this stuff lately and I think
> are starting to make some headway -- more *new* technology is not
> needed as you'll adoption severely lacking. Working with existing
> technology as a primary principle is essential.
> I created a demo hcard on my delegated OpenID:
> http://factoryjoe.com/hcard.html
> It's extremely basic, but serves as a model for capturing the type of
> data you're talking about. You could even conceal things on that page
> (like personal relationships) that are only revealed to consumers
> against whom you've authenticated.
> Anyway, would love thoughts and feedback -- and to avoid coming up
> with any new technology unecessarily.
> Cheers,
> Chris
> On 1/31/07, Dan Libby <danda at osc.co.cr> wrote:
>> Hi Lukas,
>> On Wednesday 31 January 2007 16:06, Lukas Rosenstock wrote:
>>> 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?
>> Short answer: I think that in this type of case you can present  
>> the pre-set
>> XFN values to the user, and allow them to use them as-is, or  
>> modify them.  I
>> think that the common case is that XFN relationships are bi- 
>> directional
>> ( kin, sweetheart, contact, friend, etc).  So it's a pity to throw  
>> that data
>> away if it is available.
>> Longer answer:
>> It's funny you should bring this up. I was dealing with this issue  
>> just this
>> morning. I added the capability to import XFN contacts into  
>> videntity. I ran
>> into the case where sometimes a page (eg Videntity profile pages)  
>> will have
>> incoming claimed relationships, ie:  "Sally claims she knows me as a
>> friend",
>> instead of "I claim I know Sally as a contact".  So what I did was to
>> present
>> the relationship that Sally claims as the default, but allow the  
>> user to
>> easily change it, or even exclude the relationship.
>> Further Commentary:
>> http://wiki.www.videntity.org/wiki/ 
>> Importing_Remote_User_Profile#Imported_contacts
>>> Again, for bookmarks, we don't need anything more than url,  
>>> because all
>>> meta data can be retrieved from it.
>> But what about *my* meta data?  Perhaps I have created a  
>> personalized title
>> for the URL that makes sense to me. I may have added keywords, or  
>> written
>> some notes about it. Certainly both del.icio.us and firefox  
>> bookmark manager
>> let one do these things.
>>>> 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).
>> Right. So that's why I suggested mime as a possible way for  
>> enumerating
>> well-known file-types, without having to update the spec for each  
>> one.
>> --
>> Dan Libby
>> Open Source Consulting
>> San Jose, Costa Rica
>> http://osc.co.cr
>> phone: 011 506 223 7382
>> Fax: 011 506 223 7359
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
> -- 
> Chris Messina
> Citizen Provocateur &
>   Open Source Ambassador-at-Large
> Work: http://citizenagency.com
> Blog: http://factoryjoe.com/blog
> Cell: 412 225-1051
> Skype: factoryjoe
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

More information about the general mailing list