HTML-Based Discovery with OP Identifiers

David Recordon recordond at gmail.com
Thu Dec 28 23:47:16 UTC 2006


Sitting here in Seattle with Drummond and looking through the spec.  Section
7.3.3 says:
   HTML-based discovery MUST be supported by Relying Parties.  HTML-
   based discovery is only usable for discovery of Claimed Identifiers.
   OP Identifiers must be XRIs or URLs that support XRDS discovery.

That is a bit confusing to parse so we were looking at re-wording it.  Issue
is "Claimed Identifier" is defined as possibly being a "User-Supplied
Identifier" which in turn can be an "OP Identifier" thus making this
paragraph fall apart.  This then brought up the question of why can't
HTML-Based Discovery be used for OP Identifiers?

So the reason here is that the link elements don't actually describe the
protocol version, rather the OP Endpoint URL and OP-Local Identifier.  This
thus presented us with the problem of how do we version these elements;
which we did via "openid." vs "openid2.".

Does it actually make more sense to add a new link element for the protocol
version?  This means we don't need the kludgey "openid2.x" as well as allows
support for OP Identifiers.  Thus we could have:
   <link rel="openid.provider" href="OP Endpoint URL" />
   <link rel="openid.ns" href="http://openid.net/server/2.0" />

 -or-

   <link rel="openid.provider" href="OP Endpoint URL" />
   <link rel="openid.ns" href="http://openid.net/signon/2.0" />

So a parallel to the "openid.ns" parameter within the messages themselves.

Thoughts?

--David (and Drummond too)

sending from gmail since VPN won't connect :-\
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061228/3191a4b0/attachment-0001.htm>


More information about the specs mailing list