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