Sitting here in Seattle with Drummond and looking through the spec. Section 7.3.3 says:<br> HTML-based discovery MUST be supported by Relying Parties. HTML-<br> based discovery is only usable for discovery of Claimed Identifiers.
<br> OP Identifiers must be XRIs or URLs that support XRDS discovery.<br><br>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?
<br><br>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.".
<br><br>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:
<br> <link rel="openid.provider" href="OP Endpoint URL" /><br> <link rel="openid.ns" href="<a href="http://openid.net/server/2.0">http://openid.net/server/2.0</a>" />
<br><br> -or-<br><br> <link rel="openid.provider" href="OP Endpoint URL" /><br> <link rel="openid.ns" href="<a href="http://openid.net/signon/2.0">http://openid.net/signon/2.0
</a>" /><br><br>So a parallel to the "openid.ns" parameter within the messages themselves.<br><br>Thoughts?<br><br>--David (and Drummond too)<br><br>sending from gmail since VPN won't connect :-\<br>