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

[Lukas Rosenstock]

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