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