Modularizing Auth 2.0 Discovery

Martin Atkins mart at degeneration.co.uk
Wed Feb 28 23:57:03 UTC 2007


Having reflected on people's comments a bit, I have a slightly adjusted 
set of proposals.

  1. Take the bits about parsing XRD service elements from the Yadis 
spec and call it "XRD service discovery for URIs".

  2. Have "XRD service discovery" delegate the actual mapping of a URI 
onto an XRD element to ancillary specs as before. These will define 
recognition/normalization rules for user input and how to take a 
matching URI and return an appropriate XRD element.

  3. Create "XRD discovery for HTTP URLs" which is really just the 
remaining stuff out of Yadis. *

     * HTML-based Discovery for OpenID remains a special case, but we 
can minimize the reach of this special case by stating in the HTTP URLs 
spec that if HTML-based discovery succeeds an implementation is to 
synthesize (or at least, act as if it synthesized) a 
functionally-equivalent XRD element containing Service elements for 
OpenID 1 and/or OpenID 2.

  4. Have OpenID Authentication 2 simply say “use XRD service discovery 
to find a service description for 
‘http://specs.openid.net/auth/2.0/server’ or 
‘http://specs.openid.net/auth/2.0/signon’” and then…” and go on to 
describe the interpretation of the URI element and the LocalID element.

    It'd also contain a special provision that RPs MUST support 
HTTP-based discovery, to retain the baseline functionality from OpenID 1.1.

The minimal reading for an OpenID Auth RP implementor then becomes:
     * Core OpenID spec
     * XRD service discovery
     * XRD discovery for HTTP URLs

While the idea of having three required specs is a little scary, these 
three should be able to stand alone and the latter two will be quite 
simple since they are just formed by splitting Yadis in half.

"XRD discovery for XRIs" barely needs defining since XRI resolution 
already covers most of it. Just need to bring over the 
recognition/normalization rules from the Auth Draft 11 section 7.2.

-------------------------

This also maps nicely onto a potential set of libraries:

  * 1 glue library that takes as input a URI and a list of service types 
in order of preference and returns an XRDS Service element representing 
the best match.
         findService(URI, serviceTypes[])

  * n discovery libraries which have three operations:
         isMyIdentifier(string) - determine if this library "owns" this
                                 identifier.
         normalizeIdentifier(string) - return a normalized version of the
                                 identifier.
         findXRD(URI) - retrieve an XRD element for the given URI.

     These are called by the glue library and then the glue library 
parses the returned XRD element.

  * 1 OpenID library which does:
      service = discovery.findService("=mart", [
          "http://specs.openid.net/auth/2.0/server",
          "http://specs.openid.net/auth/2.0/signon",
      ])
      endpoint = service.getURI()
      localid = service.getLocalID() || "=mart"
      // etc, etc




More information about the specs mailing list