What's new? | Help | Directory | Sign in
Google
Project Home
  
Wiki
  
Source
    
Search
for
Updated Jan 22, 2008 by heaven
Labels: Featured, Phase-Design
TestSpec  
test specification

ALPHA ALPHA ALPHA ALPHA (in development, 2008-01)

Introduction

The following is the OpenID Test Specification. To participate in the automated matrix testing of each {library,feature,version,OP-vs-RP} against every other combination, somebody should implement for each OpenID library a CGI script implementing this specification.

The specification defines specific well-known URL paths and parameter names which the test harness will use.

General Format

In general, the URLs you're to provide are of the form: 

   <BASE>/<VERSIONS>/<PATH>

For instance, 

   http://yourhostname.com:1234/library-openidtest.cgi/1.1,2.0/rp

Where the BASE is the CGI script's base. The versions is a comma-separated list of supported version numbers ("1.1,2.0"), and the rest is the function of the page. In this case, "/rp", which is a relying party implementing versions both OpenID 1.1 and 2.0.

Capability Document

An exception to the general format described above, participants in the openid-test project must support a URL of the form:

Which returns a text/plain document looking like: 

# I am an openid-test capabilities document.
# I support the following:

openid1.1
#openid2.0
#xri
#delegate

As you can see, it's one capability per line. Comments starts with a #. Blank lines ignores.

The capabilities are useful in that the test framework will skip tests if a test is marked as requiring a capability which you don't declare as supporting. This speeds up the testing, and a test result of "Skipped, due to lack of capability $X" is better than "TEST FAILED".

List of capabilities includes:

OpenID Relying Party (RP) URL formats

Show HTML forms for users: (not used by test framework itself, but helpful for people adding OpenID OP support to their site, and want to test your library)

Required GET parameters to support are:

Response format for op ""

When the op parameter is "", the expected response format is: 

OK

That is, "OK" by itself. Trailing whitespace is okay. Anything else is considered an error.

Response format for op "disco"

After discovery on a page with no delegate/local_id: 

user_specified_url: http://.../1.1/identity/will-sign
openid_provider: http://..../1.1/op
local_id:

With a delegate ("local_id", in 2.0 terms), the local_id parameter would be the URL to send to the openid provider.

Response format for op "assoc"

handle: 1200865103:PzoPTP8qjCtAqqWZogVv:33c365db4e
type: HMAC-SHA1

Examples URLs

Here are some random URLs using the options above in different ways:

Just do discovery (version 1.1 only), and emit text/plain document with information discovered:

Just associate, forcing a new association:

Do the full OpenID flow, version 2.0 only, using a specific association handle:

Identity URL formats

The basic form for an identity URL is one of:

A non-exaustive list of some combinations of the above...

# Identity URLs which return signatures right away:

# Identity URLs which fail, but after setup succeed.

# Identity URLs which fail, and then after setup do openid.mode=cancel.

... etc, etc. Again, this is a non-exhaustive list.

Other

TODO: way to tell an OP to drop an association handle.

TODO: directed identity

TODO: all combinations of Yadis/XRDS discovery

TODO: http vs. https, fallbacks, etc.