Sxip concerns with YADIS

[Josh Hoyt]

Dick,

I am glad that you have chosen to participate in this conversation.
The more we inter-operate, the better it is for all of our users.

On 12/17/05, Dick Hardt <dick at sxip.com> wrote:
> 1) Performance
>         - double the number of GETs for all HTML persona-urls

As Johannes mentioned, there is support in the specification for
carrying out the exchange with one GET through content negotiation. I
expect that the most common platforms (blog software) will support
this. It is also not difficult to support content negotiation on
common Web servers with a little bit of configuration[1].

>         - XML parsers take time to load and parse a file

Parsing HTML also takes time, and there must be support for markup
that is not well-formed, since a significant fraction of deployed HTML
is ill-formed. Since the capabilities document is small and will
likely be machine-generated, it is less likely to be ill-formed. Also,
since this is a new format, there is no legacy of ill-formed content
to contend with.

Another concern with embedding the capabilities data in HTML is that
the content at people's identity URLs may be large. In my case, the
content at my blog URL is 27KB while my YADIS capabilities document,
including six service definitions, is only 1.4KB. I am sure that
parsing a well-formed 1.4KB document will be much quicker than parsing
a 27KB document. Although it is less significant, there is also much
less data to transfer.

My arguments above do mostly depend on content-negotiation being
common, so if you do not believe that that will be the case, then your
objections are valid.

> 2) Security
>         - the user needs control over both the pesona-url AND the
> capabilities-url to secure their identity. Double the URLs, double
> the risk.

This is certainly true, but I think that in most cases, the
capabilities URL will exist in the same security domain as the
identity URL (that is, on the same server). Compromising the
capabilities document should be just as hard as compromising the
content of the identity URL. If they are hosted separately, then your
objections are valid.

> 3) Implementation
>         - all major web development platforms have high performance HTML
> parsers that present the document as a DOM. XML parsing is common,
> but is more complex than manipulating a DOM, and another thing for
> the developer to figure out.

An XML parser can give the developer a DOM to work with as well, so I
do not think that is a distinction between XML and HTML. It is also
true that the structure of the capabilities document in the current
version of the YADIS specification is simpler than HTML. Every part of
that document is relevant to the task of describing capabilities,
unlike HTML.

I hope that there will be common libraries that implement the protocol
so that the developer can be presented with a simple data structure
representing the capabilities that he desires instead of having to
write the code to parse the document himself. I admit that I'm biased
here, because I am the author of one such library, but I think that
quality libraries will be common.

>         - getting two files requires more code, and more chances of
> something being broken

Although additional complexity is a risk, common libraries will
greatly reduce this risk. It is still a very simple protocol.


> SUGGESTION:
>
> We liked the way that OpenID worked earlier with a LINK tag in HTML:
> [...]
> Given that most protocols will have their own ways of describing what
> it can do, we don't see value in a common capability file.

When I read the original YADIS specification, I was very much on the
same page. I thought YADIS was introducing unnecessary complexity into
the simple, elegant scheme that OpenID uses for discovery. It took me
weeks to come around and see value in introducing the further
complexity.

There are a few features that the new capabilities discovery scheme
has that make it superior to embedding the information in HTML:

1. It is extensible. The document format that it uses allows for
adding arbitrary information in the scope of a single service
definition. for example:

  <Service>
    <Type>http://openid.net/signon/1.0</Type>
    <URI>http://www.myopenid.com/server</URI>
    <openid:Delegate>http://josh.myopenid.com/</openid:Delegate>
  </Service>

  When using HTML to express this same information, it is split
between two <link> tags that are not obviously connected. The Type tag
also makes extremely explicit exactly what type of service is being
described, and makes it so that a developer can easily look up that
protocol. The URI-based type identifier also makes it so that a new
service can be defined without fear of namespace collisions.

2. The format allows for fallback in the case of a service failure. If
I have accounts on two different SXIP homesites, I can include both of
them and express a preference for my primary homesite. If there is a
service outage for my primary homesite, I can still use my identity,
because services can fall back onto my secondary homesite.

3. The format allows for expressing preferences about which identity
services should be used. I could include SXIP, OpenID, and LID and say
that I prefer them to be used in that order. A relying party could
then respect my preferences and make my user experience more
consistent.


In general, your criticisms are well-founded. As Johannes said, I am
glad that you are bringing your technical and practical expertise to
this conversation. Although we may not be in complete agreement
technically, it sounds like your goals in participating are similar to
mine. I wrote up a description[2] of what YADIS is that does not
include implementation details. I'd be interested to know whether this
description matches what you want to achieve from participating in
this discussion.

Sincerely,
Josh Hoyt <josh at janrain.com>
Software Engineer
JanRain, Inc.

1. http://www.openidenabled.com/yadis/configuring-a-yadis-url-using-only-apache/
2. http://www.openidenabled.com/yadis/what-is-yadis