[OpenID] Too many providers... and here's one reason

[Eran Hammer-Lahav]

This raises an interesting question of being able to list your associations in an XRDS file (which support OpenID interface), but not to designate them as your OpenID providers. This is consistent with my current (it might still evolve) interpretation of the XRDS discovery flow: that each resource should describe its own metadata, and its relationship to other linked resources.

For example, if my OpenID is provided by openid.example.com, but I am also a member of corp.example.net, my XRDS file should look like this:

<XRDS>
                <XRD>
                                <Service>
                                                <Type>http://specs.openid.net/auth/2.0/signon</Type>
                                                <URI>http://openid.example.com/endpoint</URI>
                                <Service>
                                <Service>
                                                <Type>http://xrdstype.net/association/member</Type>
                                                <URI>http://corp.example.net</URI>
                                <Service>
                </XRD>
</XRDS>

And the XRDS for http://corp.example.net will look like:

<XRDS>
                <XRD>
                                <Type>http://xrdstype.net/association/membership</Type>
                                <Service>
                                                <Type>http://specs.openid.net/auth/2.0/server</Type>
                                                <URI>http://openid.example.com/endpoint</URI>
                                <Service>
                </XRD>
</XRDS>

Of course, the xrdstype.net examples are made up. But the idea is that the user's XRDS defines to related resources, one for OpenID and another for some association. Performing discovery on the association reveals that it can be verified using OpenID. It is a different type of relationship to the user which I think is what you are getting at with the 15 memberships example. Also not that the user's XRDS did not assign any OpenID capabilities to the corp membership. That is because it has no authority to define that related resource capabilities and that belongs in the second XRDS.

EHL


From: Andrew Arnott [mailto:andrewarnott at gmail.com]
Sent: Monday, September 15, 2008 5:40 PM
To: Eran Hammer-Lahav
Cc: general at openid.net
Subject: Re: [OpenID] Too many providers... and here's one reason

You're affirmative action example is well taken.  Obviously if an OP is the best solution we should go with it.  But just imagine what all these spoons of sugar are going to do to me...

Suppose I'm a member of 15 organizations (that's conservative) between my professional, social, personal lives.  Some RP could be interested in providing specialized services if I am a member of Org XYZ.  Another RP may offer premium services if I am a member of Org ABC.

Now if every org I am a member of became an OP, then my identity XRDS file now has at least 15 providers listed.  Powerful, perhaps.  Dangerous: yes!!!  If OpenID's weakness already was that if an OP was compromised then all Identifiers that allow that OP's assertions are now compromised, then that weakness is proportional to the number of OPs that are listed in my XRDS file.  I for one do NOT want 15 Providers listed in my XRDS file.  There was a time I thought more was better, and to date I have some 5-6 OPs listed, but I've considered narrowing that down to just 2-3 to decrease my risk surface area.

Using OAuth as a post-authentication step of confirming membership is an interesting idea and should work.  In the end, whether we use OpenID or OAuth, it seems we're mixing authentication and membership, or authorization and membership, in order to just get membership.  Too bad there's not just a way to get "membership".

Yes, InfoCard managed cards solve this problem, although not as implicitly as I'd like.  I'm hoping OpenID can have a solution of its own.

On Mon, Sep 15, 2008 at 5:12 PM, Eran Hammer-Lahav <eran at hueniverse.com<mailto:eran at hueniverse.com>> wrote:
This is like applying affirmative action to cooking. "This cake calls for two spoons of sugar but we don't have enough people using lard in cakes, so I am going to use it instead..."

Looks like they want to use OpenID as an assertion verification protocol, allowing them to confirm that a given user is in fact a member of their organization. If all they want to do is assert the claim, they can use both OAuth and OpenID, each with a different set of extra features. If they use OpenID, a side-effect of this will turn them into an Identity Provider, but if this is not their intention, they should not use that identifier internally, but instead accept OpenID.

In other words, they should be an OP for assertion verification, and RP for site login.

EHL



On 9/15/08 4:45 PM, "Andrew Arnott" <andrewarnott at gmail.com<http://andrewarnott@gmail.com>> wrote:
I just spoke with an organization that wants to become a Provider so that other RP web sites can specifically tell if the logging in user is a member of this organization by whether their OpenID Identifier was asserted by that org's OP.

Ideally, I'd like this org to choose to be an RP instead of an OP because there are already too many OPs out there and not enough RPs, IMO.

How can an RP accept an OpenID Identifier from arbitrary OPs, but at each login determine whether the Identifier represents a user who belongs to a particular Organization?  Basically the Organization needs to send an assertion about the Identifier's membership, but only be willing to do so if that identifier is confirmed as having logged in successfully to that RP.  This would be easy to do if that Org was an OP, but I'm trying to reduce the # of reasons to be an OP.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080915/d4620d46/attachment-0002.htm>