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

Reply via email to