HTML-Based Discovery with OP Identifiers
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
Re: HTML-Based Discovery with OP Identifiers
On 12/28/06, David Recordon [EMAIL PROTECTED] wrote: 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. From 7.3.1: If the end user did not enter an OP Identifier, the following information will also be present: * Claimed Identifier * OP-Local Identifier The Claimed Identifier can not be an OP identifier. Therefore, I think there is not a problem with the way that HTML discovery has been specified. I don't have time to write up why right now, but I'm -1 on adding a type field to HTML discovery. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: HTML-Based Discovery with OP Identifiers
On 28-Dec-06, at 3:47 PM, David Recordon wrote: 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. To clarify it, how about we remove the Claimed Identifier term from the paragraph above, and only specify that HTML discovery cannot use OP Identifiers. This then brought up the question of why can't HTML-Based Discovery be used for OP Identifiers? Because the verification of the discovered information would be incomplete. In the case of an URL Identifier, the claimed id is the final URL. Now, if the discovered information obtained from that final URL only contains a pointer to the OP, basically anyone with an account at that OP would be able to claim s/he owns the URL -- when verifying the discovered information, there's would be no delegate / local-id to be checked and matched. If we want to allow OP identifiers to be used with HTML discovery, we need to re-examine what the claimed id is when using URLs, which would be a major change in the spec. So, unless there's an easy solution which I'm overlooking, I'd say lets keep it as it is. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
