[Openid-specs-ab] Comment on OpenID Connect Discovery (1.0 Draft 07)

[Owen Shepherd]

Discovery depends upon Simple Web Discovery [SWD]. Is there a posted rationale for the choice of SWD over LRDD (See [host-meta]) anywhere?

SWD does have the notable advantage of being simpler (as may be expected given its title), however
It has poorly defined delegation caching semantics (It is undefined how SWD's delegation caching is intended to interact with the caching mechanisms built into the HTTP protocol). 
It has onerous requirements on the user - "the caller MUST redirect all SWD requests for that domain to until the expires time has passed." implies that the caller is required to maintain a cache of all redirections it has received for the given time period. This is not likely to be feasible
It has a hard requirement on HTTPS, thus making it hard to genericise to applications which do not require the security required by OpenID

In combination with the OpenID Connect Discovery specification, this has other issues:
It is impossible to make revisions to the discovery specification which change the service type without requiring multiple requests for backwards compatibility
Related to the above, it requires that end users perform multiple requests if they wish to find more information about the user

It would make sense to me for OpenID Connect to build upon [WebFinger], as
Several major providers, including Google and Yahoo, have already implemented WebFinger support for their user accounts. 
The same LRDD request that would be used to discover the OpenID Connect endpoint can be used to gather other useful information about a user
LRDD is easily extended in order to support discovery of new endpoint types - and can already be used (via an informal specification) to discover OpenID 2.0 endpoints
Many applications which would benefit from the integration with OAuth brought about by OpenID Connect (such as [OStatus]) have already standardised upon LRDD and WebFinger

As an example case where LRDD provides useful additional functionality, I can see web applications theoretically supporting the following functionality: 
User is provided with a "web identity" text box into which they can enter
An "E-Mail address-like" ID (e.g. user at example.com), to be looked up using WebFinger
An "URL-like address" (e.g. example.com/user), to be looked up using LRDD after prepending http[s]
A fully formed URL, to be directly looked up using LRDD
(A todo issue: in the URL-like cases, should we fall back to parsing HTML link elements to support delegation?)
Some client side JavaScript, as the user types, uses XMLHttpRequest in order to perform lookups on these entered addresses
A popup can appear below the login box saying "Login as <your name>", featuring the user's name and avatar, automatically gathered by performing a PortableContacts lookup for the user
When the user presses enter, or the login button, the authentication flow can be started quickly as the JavaScript code on the client has already done some of the hard work

I do not believe that the simplifications made by SWD over LRDD are warranted or wise, and would much prefer to see OpenID Connect revised to build upon the WebFinger and host-meta specifications. 

== References (where not included in the discussed specification)
[host-meta]	http://tools.ietf.org/html/rfc6415
[WebFinger]	http://tools.ietf.org/html/draft-jones-appsawg-webfinger-00
[OStatus]	http://ostatus.org/


-- Owen Shepherd
http://www.owenshepherd.net/
owen.shepherd at e43.eu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120105/15089d58/attachment.html>