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 :-\
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs