Skip to end of metadata
Go to start of metadata

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

<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: 19)

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>

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

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

    <p>we just implemented OpenID at SourceForge.net using Zend_OpenId and our top priority issue from users is the lack of support for Yadis, XRDS, i-names, etc.</p>

    <p>how can we help revive activity on this proposal and get it into the roadmap for future core releases?</p>

  2. May 30, 2008

    <p>If you're really stuck in the meantime, check out PEAR::Services_Yadis. It's almost identical in every way (except it's beta, and needs some refactoring for a new release). The above proposal's code will largely be the same thing with a different namespace once it's reviewed and any comments integrated.</p>

    <p>It strikes me the proposal references the original Summer 07 source code. If it helps I can update the proposal and present a link to Zend namespaced code in a repository.</p>

  3. May 30, 2008

    <p>thanks Padee <ac:emoticon ac:name="wink" /> we'll look into PEAR::Service_Yadis.</p>

  4. Jun 18, 2008

    <p>A note to whoever is reviewing this proposal - please note it's entirely possible I'll be pulling this entire component to pieces. Given the proposal's age and lack of updates, it may need refactoring to support incoming changes. Since it's not accepted into the framework as yet, this means changes to the API, use cases, and test suite are likely.</p>

    <p>Points worth noting:</p>

    <ol>
    <li>Yadis will be integrated into the Extensible Resource Identifier (XRI) Resolution Version 2.0 Specification. The use of the Yadis namespace may become deprecated.</li>
    <li>It has been confirmed that OAuth 1.1 (and OAuth 1.0 with Extensions) will use the Yadis protocol for service provider discovery with a condition that such discovery will support a new XRDS-Simple Specification.</li>
    <li>Extensible Resource Identifier (XRI) Resolution Version 2.0 is at Committee Draft 3 and the changes it introduces will need to be incorporated.</li>
    </ol>

    <p>Main point here is that the proposal supports the specification landscape from over a year ago when I proposed this. A year is a long time in web services and new specifications, draft extensions and clarifications have built up a stock of needed alterations. I hope it doesn't have any fundamental impact on the API and it's something I'm looking into.</p>

    <p>If there's anything I can do to speed up a review, please let me know.</p>

  5. Jul 10, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comment</ac:parameter><ac:rich-text-body>
    <p>This proposal is approved for development in the standard/incubator with the following conditions and recommendations:</p>

    <ul>
    <li>Please rename to Zend_Yadis. We feel that while this operates over HTTP, it is less of a service as it is a method for determining identity and/or information regarding an identity provider, and as such deserves its own top-level namespace.</li>
    <li>We recommend using constants for the various OpenID specifications to simplify usage (see UC-01 as an example – where you loop through the service types)</li>
    </ul>
    </ac:rich-text-body></ac:macro>

  6. Mar 18, 2009

    <p>Same question, Paddy. <ac:emoticon ac:name="smile" /> What is the status of this proposal? Should it be archived?</p>

    1. Mar 20, 2009

      <p>It's mostly in the Incubator but its down the list of my priorities and lacks sufficient unit tests for a release. It's reasonable to archive it for the time being until I can swing back to it, or until someone gets around to upgrading the Zend_OpenID component and can either take it over or push me into getting tests done <ac:emoticon ac:name="wink" />. Functionally, it's working as is - I just didn't get around to making my usual TDD approach or it would be tested and released already.</p>

      1. Mar 22, 2009

        <p>Paddy,</p>

        <p>We (sf.net) are very interested in this component. I'm negotiating some time/resources for us to spend on a couple of my own ZF components, and I think we'll be willing to help you finish this one as well, if you're up for it.</p>

        <p>-L</p>