Open Issues

From Yadis

This page attempts to collect open issues against the current draft of the spec. To propose a resolution, or contribute to discussion, use the Yadis Mailing list or the discussion page (select 'Discussion' above) or make a change proposal (see Change Proposal HowTo).

Contents 1 Open Issues (Current) 2 Open Issues (Earlier) 2.1 Issue: What is the service discovery protocol? 2.2 Issue: What is Yadis? 2.3 Issue: How do we slow the rate of change, and finally freeze a specification so implementors can support, and test against a specific Yadis version? 2.4 Issue: What do we call the box into which the user enters their Yadis-enabled identifier? 3 Open Issues (Deferred)

Open Issues (Current)

• OpenID Specification Open Issues

Open Issues (Earlier)

Issues that were debated:

Issue: What is the service discovery protocol?

Yadis is an service discovery system allowing identity sytem relying parties (aka identity consumers or membersites) to determine automatically, without end-user intervention, the most appropriate identity protocol to use to authenticate or obtain information about a proffered identifier.

The most immediate open issue is to determine the Yadis service discovery protocol. Draft-002 describes the process we are using and records the requirements and alternatives. Version 1.0 is at Yadis Specification.

Please contribute by reviewing the draft and making a change proposal.

Issue: What is Yadis?

Here are some of the definitions that we have heard so far. Because some of them are mutually exclusive, we need to decide what are trying to accomplish here.

1. A project, and a protocol for service discovery (and no more)
2. A project, and a protocol for service discovery and definitions how to use it in conjunction with LID, OpenID and i-names (maybe others)
3. A project, and a protocol for merging LID and OpenID, and potentially others (given that Yadis defines an framework for doing so)
4. A project, and a protocol that over time, will collect and standardize many digital identity related protocol features, as soon as there is agreement. Currently, there is only agreement on service discovery and profile exchange, but once there is agreement on single sign-on, for example, that agreement would also be subject to Yadis. Agreements on other services could follow.
5. The project and protocols necessary to construct the REST-ful subset of the identity meta-system
6. A ("The"?) REST-ful identity meta-system

Arguments pro and con are collected at Talk:Open_Issues.

Issue: How do we slow the rate of change, and finally freeze a specification so implementors can support, and test against a specific Yadis version?

During the development of Version 1.0, the wiki started out as a free-for-all, everybody could change anything at will. This was great for as long as the specification was being put together, but as implementations started, we slowed down the process and finally started freezing the spec into numbered versions. Obviously, we couldn't have anybody edit a frozen version of the specification after that time. (Of course, development of the final Version 1.0 proceed, but with an editor making the changes.)

We used the wiki for specification development and discussion, and use the OpenOffice/PDF version (see Yadis Documents) as the official, version-controlled and archived baseline.

Arguments pro and con are collected at Talk:Open_Issues.

Issue: What do we call the box into which the user enters their Yadis-enabled identifier?

We currently call it 'My URL', which is bland, non-descriptive and maybe not quite correct anyway. We didn't want to say "LID or OpenID URL" or something as convoluted as that, in particular as new protocols and technologies join Yadis as supporters and we would have to extend the list. Also, 'Yadis' is considered a project name, rather than something that is end-user facing.

Open Issues (Deferred)

Please enter here open issues known but deferred for later discussion and decision.