[OpenID] AddId! - A useful idea of mine?!
Lukas Rosenstock
inbox at lukasrosenstock.net
Wed Jan 31 22:06:17 UTC 2007
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
More information about the general
mailing list