[OpenID] DISCUSSION relating to OpenID Discovery 2.1

David Fuelling sappenin at gmail.com
Mon Dec 29 18:11:44 UTC 2008


Peter,

Thanks for your input...see my replies inline.

david

On Mon, Dec 29, 2008 at 4:36 PM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  The main problem I have is …you are changing the character of XRDS (and
> XRI 2.0 resolution).
>
> Yes, but I'd be open to accomplishing these ideas without doing so.

>
>
>  In 1, you are turning metadata discovery into a authorization/control
> framework. Won't be long before you will want a "#include QXRI" line in the
> XRDS, that imports XRDs from a superior policy authority, and require the
> XRI client resolver to now to "augment" the XRDs with those from the control
> authority. If OpenID needs an policy-based authorization framework, let's
> consider that in its own right (and there is LOTS AND LOTS of previous work
> to draw on). Let's not break the (nicely working) metadata model, tho.
>
>
>
Well, it already is an authorization/control framework.  The value of the OP
endpoint in your XRDS document is what controls what your OP is.  Proposal
#1 merely extends this to say that you need 2 OP's instead of one, and
possibly only for certain sites.


> In 2, why doesn't XRI already do exactly what you want? Surely, the
> intelligence you want is in the query syntax, and that is precisely what XRI
> resolution gives you? The notion that one discovery agent would proxy to n
> other discovery agents based on criteria from the resolution request seems
> important (and, again, what other sso discovery protocols already do).
>
> Most likely I'm just too ignorant of XRI to actually know how it works in
full.  Can you provide an example of how I could do #2 with existing
mechanism?

In my #2 "spec" (it's not nearly fleshed out enough to be called such a
thing) I have three methods to do OP Delegation.  "Service" delegation
already is possible with current XRI mechansims, I agree (I note that
scenario just to clarify how I think OpenID Discovery should work with
regard to OP's).  But it is less apparent to me how to do method's two and
three of my "spec" (i.e., pick an OP based on the RP's domain, or based upon
some feature of the OpenID transaction).


>
>
> In 3, what is wrong with the XRI extension model? It seems to do exactly
> what you want.
>
>
>
Hmmm...this is a possibility, but my thinking was that these discovery
extensions would be OpenID specific.  In other words, the notion of
overriding the definition of XRDS/XRD "priority" attribute is pretty
specific to OpenID discovery, and specific to the "2-headed auth" example in
particular.  I'm not opposed to making these ideas into a more generic XRI
extension, but I'm not sure they're really that generic.  Plus, it would be
nice to have something that is "OpenID Endorsed" (or condemned) in order to
ensure it makes it into OpenID best practices (e.g., always do this....or
NEVER do this).


> Now I can see an argument that just as folk could not typically
> adopt/implement the X.500 DAP query model, but could adopt simpler queries
> expressed  in simplified ldap urls, so we might need to make a simplified
> XRI resolver based on lxri:// urls… building on the momentum that wants to
> simply parse an XRDS stored in a static file (rather than a full-power XRDS
> stream generated  as a result of resolving an XRI query seeking metadata
> from the i-broker network)
>
>
>
Yes.

> If 2 and 3 above were expressed in terms of: here is the lightweight
> profile of XRI tuned to those 3 purposes, and its carefully tuned to be easy
> to program…that might fly as a work item. Its taking the  current design and
> simply making it easier to adopt, focusing on
>
>
>

>
>
>
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *David Fuelling
> *Sent:* Monday, December 29, 2008 6:25 AM
> *To:* specs at openid.net; general at openid.net List
> *Subject:* [OpenID] DISCUSSION relating to OpenID Discovery 2.1
>
>
>
> Not sure if this made it through to everyone due to the mail list
> malfunction, so resending just in case.
>
> david
>
> ---------- Forwarded message ----------
> From: *David Fuelling* <sappenin at gmail.com>
> Date: Fri, Dec 26, 2008 at 6:58 PM
> Subject: DISCUSSION relating to OpenID Discovery 2.1
> To: "specs at openid.net" <specs at openid.net>, "general at openid.net List" <
> general at openid.net>
>
>
> 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-general/attachments/20081229/37cf6b0d/attachment-0002.htm>


More information about the general mailing list