Supporting point 2 (user with a v1 OP and a *separate* v2 OP) seems a bit unnecessary. A single OP can support v1 and v2 RPs at the same time. Point 2 is the sort of corner-case that can be supported by a yardis file, but needn’t be supported by the simple HTML discovery alternative. My vote would be to keep openid.server and openid.delegate (instead of openid2.provider and openid2.local_id) and add openid.version.
P.S. The spec should talk about <link …/>, instead of <LINK …>, elements. It does this in the §A.4 “HTML Identifier Markup” example, but not in §7.3.3 “HTML-based discovery”. Version 1.1 used <link …>; HTML is case-insensitive so <link …> is ok; XHTML is case-sensitive so <LINK …/> is not acceptable. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Wednesday, 31 January 2007 12:50 PM To: Recordon, David Cc: specs@openid.net Subject: Re: DRAFT 11 -> FINAL? On 1/30/07, Recordon, David <[EMAIL PROTECTED]> wrote: > Yeah, I'm not a big fan of openid2.* though it was the simplest method > of fixing up HTML discovery to work with multiple protocol versions. I > know Josh thought about this more than I did though. 1. Before authentication is initiated, the RP needs to determine what the protocol is. This could be done via discovery on the OP, but there has been general rejection of adding yet another discovery step. 2. A user may have one service that provides OpenID 1 and another that provides OpenID 2. If this is the case, then the version information needs to be bound to the link tag that contains the information. Given (1), the information needs to be embedded in the HTML markup. Given (2), the information needs to be tied to the specific link tag. For example: <link rel="openid.server" href="http://op.example.com/openid1"> <link rel="openid2.provider" href="http://op.example.com/openid2"> vs. <link rel="openid.server" href="http://op.example.com/openid1"> <link rel="openid.provider" href="http://op.example.com/openid2"> <link rel="openid.protocol_version" href="http://specs.openid.net/auth/2.0"> While it is true that since the link relationship names changed, the "openid2" is technically redundant, I think it is much clearer to everybody what is going on if the link relationship contains the version number. If the protocol version were to keep changing, I'd argue for a different solution. Josh _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs