DISCUSSION relating to OpenID Discovery 2.1

David Fuelling sappenin at gmail.com
Fri Dec 26 18:58:59 UTC 2008


All,

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 OpenID 2.1
Discovery WG wiki
page<http://wiki.openid.net/Working_Groups%3AOpenID_Discovery>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.

Thanks!

David


   1. *Enabling two (or more) headed OP authentication*
   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: OP
MultiAuth<http://wiki.openid.net/OP-MultiAuth>.
   XRI Resolution 2.0 seems to currently prohibit this by default per section
   4.3.3: "*If two or more instances of the same element type have identical
   priority 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.*"  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.

   2. *OP Delegation based upon various characteristics of an OpenID
   transaction*
   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 (*.
   example.com); 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: OP Delegation <http://wiki.openid.net/OP-Delegation>.

   3. *Discovery Extensions*
   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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081226/45efd190/attachment-0001.htm>


More information about the specs mailing list