Anonymous user


From Yadis

Jump to: navigation, search

Note: This page describes a draft set of changes to the Yadis spec. The changes proposed here have now been incorporated, either in whole or in part, into the main spec. This draft remains for historical reference only.

The goal of the changes in Draft 1 is to make a few changes that remove the OpenID- and LID-centric elements of the original Yadis proposal and work towards a generic layer of abstraction over existing identity-based capabilities.


Summary of Changes

  • Both the page at the identity URL and the capability document can be just a static document on your website.
  • The endpoints for the declared authentication services are configurable rather than assumed to be the same as the capability document.
  • The trick of requesting with ?meta=identity to as a hint to provide a capability document has been replaced with the use of the HTTP Accept header, which is less likely to conflict with existing applications at the identity URL and can be implemented using the content negotiation capabilities in Apache. The indirection through HTML is still provided for those who are unable to switch based on the Accept header.
  • OpenID's delegation capability is not supported through Yadis. Yadis itself provides the same end result, so OpenID-specific support is unnecessary.
  • The LID profile exchange feature is no longer part of the core spec. Profile exchange is just another capability, and since Yadis does not affect the underlying LID protocols the usage of LID profile exchange is no longer included.

Editor's Notes

This draft does not change the currently-specified capability document format, and so the new Impact chapter uses the existing format in its examples. However, this proposal does not include any particular capability document format, as the choices are currently being discussed elsewhere.


Draft Specification

The chapters affected by this draft are shown in bold. Other chapters are unchanged.

  1. Background
  2. Goals
  3. Architectural Assumptions
    1. Fully decentralized, and no one point of control
    2. Let many (interoperable) flowers bloom
    3. URLs as identifiers
    4. REST-ful and easy to use for developers
  4. User Scenarios
    1. Scenario: Authentication at website
  5. Yadis Protocol
    1. Capability Discovery Protocol
    2. Authentication
    3. Profile data exchange
  6. Formats
    1. application/x-meta-identity
  7. Impact on LID and OpenID
  8. Examples
    1. Log on at an OpenID site (non-delegated case)
    2. Log on at a LID site (non-delegated case)
  9. Terminology
    1. Developer terminology
    2. End-user terminology
  10. Possible Future Work
  11. For more information
Personal tools