Yadis FAQ
From Yadis
Contents |
Feature Questions
Would it be reasonable to use Yadis for non-identity service discovery?
ie, I want to know if a site has APIX, I get their Yadis XML which has a node referencing APIX and so I know they have it...
Absolutely. For example, you can consider the frequent "link" headers in HTML to be a shorthand for full YADIS, just like OpenID's openid.* tags in HTML have been re-explained as shorthands for entries a proper YADIS file. YADIS files can be considered collections of metadata for URLs, and because YADIS is an extensible format, just about any metadata can be represented. Without extensions, the basic structure is that each URL can have N services associated with it, each of which has one or more service types. For example, one service type might be "this is how you add content to this page", another "this is where you find the FOAF file that goes with this identity URL."
What existing services can we expect to support Yadis?
Given the people that initiated Yadis, you can probably guess at least some of them.
Johannes Ernst (NetMesh): We are have added support for Yadis in NetMesh InfoGrid, and in mylid.net, our hosted personal identity service. See also downloadable code from netmesh.org/download.
David Recordon (Six Apart: We plan to support Yadis in the LiveJournal.com codebase which is also in use by other sites such as DeadJournal.com and GreatestJournal.com, both who are already running and using OpenID.
Will I be able to Single Sign On with Yadis?
That's the first and most basic use case, so absolutely: Yes.
For example: This wiki is now Yadis-enabled. Instead of having to sign up for yet another account, users can identify themselves by:
- by bringing their own LID
- by bringing their own OpenID
- by bringing their own i-name (to be done, see also Yadis Logon)
Will I be able to Single Sign Off with Yadis?
If I sign off from one member site, all the sites I have signed on including the home site will be logged off?
Yadis itself does not define a single-sign-on or sign-off protocol; it delegates to protocols such as OpenID and LID/GPG. It is up to those protocols whether this is supported. (However, OpenID currently does not address this. While LID/GPG could be used, we don't know of an implementation that actually does it).
Compliance questions
Is supporting the profile exchange a requirement for all Yadis-compliant servers, or is it an optional feature?
Most servers will probably want to implement a basic profile query so that they can greet users with "Hi Bob!" instead of "Hi http://example.com/bob!". However, profile exchange is optional.
Why do we need both OpenID and LID authentication?
If we started on a green field, we might not (although there are substantial arguments both in favor and against public-key-based and shared-secret-based authentication). But we don't start on a green field, so we currently leave both LID and OpenID authentication in place.
In the future, we may want to work on a a single authentication scheme, potentially also considering other SSO schemes like the ones from SAML, Liberty, Sxip, etc.
Do I need to implement both OpenID and LID authentication?
Identity servers can use Yadis to declare what authentication mechanisms are supported. Relying parties (aka identity consumers) likely will support each mechanism that their users might want to use. Yadis simply assists the relying party in selecting the appropriate mechanism.
Supporting only OpenID authentication or only LID authentication is fine, as long as it is acceptable to the site that certain users may not be able to authenticate with their identity URL.
Can Yadis support non-URL based identifiers, such as i-names?
Yes, i-names are resolvable to URLs.
Security Questions
Can Yadis be abused by phishers?
Yadis itself doesn't really add to or reduce security; the integrated identity systems (such as LID, OpenID) are responsible for security including anti-phishing measures.
Upgrade questions
If all I want is OpenID, what does Yadis actually add?
As an end-user, you will be able to enter your OpenID URL into a Yadis-enabled server and have the server automatically detect that the URL is an OpenID identifier and, assuming it supports OpenID, go ahead and do the authentication with no further questions.
If all I want is LID, what does Yadis actually add?
As an end-user, you will be able to enter your LID URL into a Yadis-enabled server and have it automatically detect that the URL is a LID identifier and, assuming it supports LID, go ahead and do the authentication with no further questions.
If I have a current OpenID or LID implementation, what is the minimum amount of work I need to do to be Yadis-compliant?
You create an XRDS file that describes the feature(s) in your implementation. You reference the URL of that XRDS file when your identity URL is accessed. That's it.
If you have an existing implementation, adding Yadis support is trivial. Code is available at Yadis Libraries.
Project Goal questions
What are the *real* problems Yadis is going to solve, and how?
A Yadis enabled server provides a single box to enter your Yadis ID. You enter http://me.somewhere.com/ into the box. How do we know what kind of identfier it is? It might be an OpenID, LID or some other kind of Yadis ID.
Two options:
- Ask you to choose "OpenID", "LID", "..." from a list in the form. Pretty lame. You don't know or care about the difference between OpenID and LID.
- Have a standard way that a relying party can ask the identity server what kind of server it is. Or, more accurately, what protocols it supports. This is what Yadis does for you.
So what we have is a simple mechanism for determining for a given identity URL what protocol should be used to talk to it without asking the user. That way multi-protocol servers can be created without requiring users to understand how the technology works. Additionally, Yadis allows for the discovery of additional services such as profile exchange, user-accompanied RPC and so forth.
This is all done via a document using a simple service declaration format and some conventions for retrieving that document. See Yadis Specification 1.0 for more information.
Why is Yadis needed? Can't the same functionality be done just with tags?
(asked by Dick Hardt)
- To expand on the question: OpenID uses
tags in the HTML of the identity URL to indicate that the URL is an OpenID identifier, to indicate where the OpenID identity server can be found and which alias to use. Couldn't the same functionality that Yadis provides be accomplished much more easily by simply adding additional tags, each specifying a new capability? (let's call this the "link-only approach")
Answer: Some of the functionality could be provided with the link-only approach, other functionality cannot be provided (at least not easily), and there are substantial downsides to this approach as became clear during initial YADIS discussions:
- the link-only approach is limited to HTML at the identity URL. If a different content type was desired at the identity URL, an equivalent mechanism would have to be defined for each content type (e.g. if it is RSS, look for this tag, if it is PDF, parse PDF this way etc.). Yadis solves this problem through the X-XRDS-Location header on the HTTP protocol level.
- the link-only approach does not (easily) support provider-driven identity adoption: the provider would have to filter, and dynamically insert, the link tags at static HTML files they host.
- Yadis supports both provider-driven identity adoption and user-driven identity adoption
- we expect the number of capabilities to rise rapidly. For example, LID already knows about a dozen profiles (aka Yadis services), and we are only at the beginning. It becomes practically infeasible to, say, insert a hundred additional
tags into an HTML page. - The Yadis approach, on average, uses less bandwidth (e.g. search engines do not need to pull a lot of
tags) - HTTP Caching can be configured separately between content (e.g. the HTML) and identity meta-data (the Yadis information)
- If a hosting provider offered identity capabilities to their customers, but made it optional for their customers whether they wanted their "home pages" to be identity-enabled or not, it is much easier for the hosting provider to instruct their customers to add a single tag to their HTML document, pointing to a provider-maintained Yadis resource descriptor, than it is to ask them to track all the evolving services with their HTML files that the host supports.
tags, by their nature, can only express a very simple information structure, i.e. name-value pairs. The Yadis resource descriptor, on the other hand, is a full-fledged XML file that can be extended with only few restrictions. That way, Yadis can express much richer meta-data about identity capabilities than one could hope to express with tags. For example, Yadis can express that a service supports multiple types at the same URL; this would be very hard to express with tags only - another example for richer meta-data would be Yadis' ability to express preferences between services (e.g. "this Yadis URL can do both OpenID authentication and LID SSO; I prefer RelyingParties to use this one, but they can use the other if they must")
