All,<br><br>I'd like to propose that the following ideas be considered as discussion points in the OpenID 2.1 Discovery WG. I've updated the <a href="http://wiki.openid.net/Working_Groups%3AOpenID_Discovery">OpenID 2.1 Discovery WG wiki page</a> to reflect these ideas, and have provided two very rough-draft proposals (currently formulated as extensions) to juice up the dialog. The ideas are summarized below -- I'd be curious to hear any and all feedback.<br>
<br>Thanks!<br><br>David<br><br><ol><li><strong><em>Enabling two (or more) headed OP authentication</em></strong><br>The idea here is to allow an end-user to specify two (or more) OP's
in the <Service> portion of their XRD so that an RP MUST receive
auth assertions from both OP's before granting access to protected
resources. See a rough-draft idea proposal here: <a href="http://wiki.openid.net/OP-MultiAuth">OP MultiAuth</a>. XRI Resolution 2.0 seems to currently prohibit this by default per section 4.3.3: "<em>If two or more instances of the same element type have identical <span class="XMLPath">priority</span>
attribute values (including the null value), the consuming application
SHOULD select one of the instances at random. This consuming
application SHOULD NOT simply choose the first instance that appears in
XML document order.</em>" Thus, in order to indicate to the RP that
both OP URI's should be used at the same time, an aditional
<Type> element is used to signify that identical priority URI's
should be used together for the purposes of OpenID Auth.<br><br>
</li><li><em><strong>OP Delegation based upon various characteristics of an OpenID transaction</strong></em><br>The idea here is to allow an end-user to delegate authority over a
particular OpenID Identifier to divergent OpenID Providers (OP's),
depending on certain characteristics of a Relying Party and/or certain
characteristics of an OpenID transaction. For example, an Identifier
might specify a different authoritative OP depending on the
OpenID-related Service being employed (e.g., OpenID 2.0, OAuth, or
others); the RP Domain (*.<a href="http://example.com">example.com</a>); or a pre-defined service Class
(e.g., one OP for single-factor auth, and another OP when two-factor
Auth is required). By providing OpenID Identifiers with the ability
to specify multiple OP's based on particular characteristics of each
OpenID transaction, end-users will be able to utilize the best OP for
any particular OpenID transaction as they see fit (i.e., more control
in the hands of the user). See a rough-draft here: <a href="http://wiki.openid.net/OP-Delegation">OP Delegation</a>.<br><br>
</li><li><em><strong>Discovery Extensions</strong></em><br>The OpenID Discovery specification should define ways for discovery
to be extended by other services. For example, the
OAuth+OpenID specification may want to peform discovery in slighly
different ways than regular OpenID Auth 2.1 does. Likewise, ideas numbers 1 and
2 above could be implemented as extensions to Discovery instead of
being included in the main 2.1 Discovery specification.<br>
</li></ol>