Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Yadis Component Proposal

Proposed Component Name Zend_Yadis
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Yadis
Proposers Pádraic Brady
Matthew Weier O'Phinney, Zend liaison
Revision 1.0.7 - 04 July 2007 (wiki revision: 18)

Table of Contents

1. Overview

Yadis is a specification which details a protocol enabling user applications to discover a list of services a Yadis ID has available for use. Although it sounds fuzzy, it's purpose is relatively simple. Based on a valid Identity (e.g. OpenID Url, Sxip ID, XRI, Yoke) it enables an application to locate and describe that Identity's available services (e.g. authentication services, attribute exchange services, etc).

In OpenID, Yadis allows the Relying Party (say a PHP blog) to discover the User's authentication service, it's location, and it's type. In addition, it may also allow the Relying Party to discover whether a Simple Registration Extension service is available (which allow the Relying Party request private User details like email, real name, etc).

The data discovered about services is stored as an XML document called an Extensible Resource Descriptor (XRD). The Yadis Specification details the syntax for this XML document and how its data should be handled when manipulating it. This proposal captures these requirements.

Since Yadis is a standalone specification, it is extensible and allows for the discovery of any service which is tied to a specific Identity (URL or otherwise). It is a requirement for implementing OpenID 2.0 which will utilise Yadis 1.0 to enable Relying Parties locate an OpenID Provider's authentication service. It is also utilised by Sxip ID, XRI Identifiers, Light-Weight Identity (LID), Yoke and mIDm. Yadis is by no means tied to any single Identity broker or service provider.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • Zend_Yadis must implement the Yadis Specification 1.0 including the Yadis protocol for discovering the XRDS document for an identity.
  • Zend_Yadis must implement discovery where the Yadis ID is a valid URI
  • Zend_Yadis must implement discovery where the Yadis ID is an i-name (XRI)
  • Zend_Yadis must be able to parse an XRDS document into a set of Zend_Yadis_Service objects each holding URL/Type and other data capable of lookup via an XPath query on the object.
  • Zend_Yadis will use SimpleXML for parsing XRDS documents.
  • Zend_Yadis will support IRIs (Internationalised Resource Identifiers) once they are supported by the core Zend_Uri component of the framework.

4. Dependencies on Other Framework Components

  • Zend_Service_Abstract
  • Zend_Service_Exception
  • Zend_Http_Client
  • Zend_Uri
  • Zend_Exception

5. Theory of Operation

The purpose of Zend_Yadis is to implement, in full, the Yadis Specification 1.0.

Upon receipt of any viable Identity (URL, XRI, OpenID, other), Zend_Yadis may be called upon to retrieve a list of all services available for that Identity in an iterable list ordered by priority. The definition of "priority" in this case is as defined by the XRI Technical Committee's XRI Resolution 2.0 working draft.

The initial Identity must either be a URI, or another form capable of being normalised to a URI. XRI normalisation allows for the use of the XDI XRI proxy since HTTP clients typically have no native XRI resolution support.

The normalised URI is requested by a HTTP client. Valid responses are outlines in the Yadis Specification 1.0 and include an XRD document, a response header indicating the location of a valid XRD document, or an XHTML document containing a meta tag which points to a valid XRD location.

Depending on the response, a second HTTP request may be initiated to retrieve the XRD document from it's actual location. Alternatively an Identity may serve an XRD document if a suitable "Accept" header was passed with the HTTP request.

The actual format and ordering of Services, and their constituent data, in the XRD document must follow a strict "priority" standard which (as stated by the Yadis Specification 1.0) is the OASIS XRI Resolution 2.0 specification. This rules the order in which Service objects are iterated across in the collection result object.

At this stage, the result may be passed to a specific handling client - for example, Zend_Openid - which will locate a compatible service type, and utilise its data in order to communicate requests to the discovered service it requires.

6. Milestones / Tasks

  • Milestone 1: Implement basic service using Zend dependencies
  • Milestone 2: Unit Tests and class refactoring
  • Milestone 3: Debugging and Use Case testing
  • Milestone 4: Documentation

7. Class Index

  • Zend_Yadis
  • Zend_Yadis_Xrds_Namespace
  • Zend_Yadis_Xrds
  • Zend_Yadis_Xrds_Service
  • Zend_Yadis_Service
  • Zend_Yadis_Xri
  • Zend_Yadis_Exception

8. Use Cases

UC-01

Retrieve an OpenID service description based on URL

UC-02

Retrieve an OpenID service description based on XRI i-name

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.