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

Tue Sep 16 06:30:51 UTC 2008

Ignroing the desire to keep membership secret, isn't  even the original delegation model of openid 1 more or less sufficient for openid grade (rough and ready)  assurances?

One posts as many delegation meta files at as many organizations as one want to allow one during url data etry to specify ones membership-name to the rp, which delegates to the opby std discovery. If metadata exists on theorganization site, the organization obviously has "some role" in managing part of the users (multi homed) identity.

Without a formal signature (like in xri) its hard to do much better with openid1.

-----Original Message-----
From: Tatsuki Sakushima <tatsuki at nri.com>
Sent: Monday, September 15, 2008 10:39 PM
To: Andrew Arnott <andrewarnott at gmail.com>
Cc: Peter Williams <pwilliams at rapattoni.com>; general at openid.net <general at openid.net>
Subject: Re: [OpenID] Too many providers... and here's one reason

Mixi, the largest SNS in Japan, does membership authentication in a
simple manner. They just let RPs specifiy URL of OP that users should
have membership. However, this way won't reduce the number of OPs that
users have to manage even thought it is straight forward and easy to
understand.

I think that having a master OP to manage all other OPs that users have
membership with. But users must manage the list somehow. From users'
perspective, I don't know which is a better way to do it.

Another way to think this is that RPs should consider they engage
directly to users through OPs with certain conditions such as providing
information that RPs require. We also should think about purposes of
membership. Do they have to belong to organizations that RPs specify to
get a deal?

Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.

Andrew Arnott さんは書きました:
> That's sounding like what I was hoping existed.
>
> Now, since I'm hoping to separate authentication from this membership
> test, and if I didn't want my membership in Org XYZ to be public
> knowledge, from a user's perspective it seems the only way to get this
> to work would be this:
>
>    1. I log into RP using an Identifier of my choice, and an asserting
>       OP of my choice
>    2. The RP is interested in my membership in Org XYZ, so it asks Org
>       XYZ if my Identifier is a member of the org.
>    3. Similar to OpenID OP's list of sites I trust, Org XYZ checks if
>       the requesting RP is trusted by me.  If it is, then it just
>       answers yes.  If not, it tells the RP to take the long route.
>    4. The long route would be the RP redirecting me to Org XYZ to go to
>       a page where I would grant permission for the RP to find out that
>       I am a member.
>    5. The redirect (like OpenId) would tell the RP that I am in a
>       confirmable way.
>
> Blah, that sounds way just like the org being an OP.  So maybe for
> purposes of this investigation we'll just say it can be public
> knowledge, but confirmable the way Peter just described.
>
> On Mon, Sep 15, 2008 at 5:30 PM, Peter Williams <pwilliams at rapattoni.com
> <mailto:pwilliams at rapattoni.com>> wrote:
>
>     Couldn't this be handled by the XRI support, in the openid 2 world?
>
>     Doesn't the XRI resolver allow the organizational claim to be tested?
>
>     XRI essentially has a yellow-pages resolver built in. For any yellow
>     page index, you can resolve a name via that particular naming path.
>     The XRI resolver thus tests that one is listed in a particular
>     "organizational" index, or which there can be n. In trusted XRI,
>     furthermore, the SAML assertions would provide additional proof that
>     the particular resolver listener is authorized to speak for those
>     organizations. In the HXRI trusted resolver variety, the usual trick
>     of the proxy resolver having n*1000 SSL server, one per
>     organization, would be sufficient to know that the listener speaks
>     for the organization (over https)
>
>     -----Original Message-----
>     From: general-bounces at openid.net <mailto:general-bounces at openid.net>
>     [mailto:general-bounces at openid.net
>     <mailto:general-bounces at openid.net>] On Behalf Of Dick Hardt
>     Sent: Monday, September 15, 2008 5:12 PM
>     To: Andrew Arnott
>     Cc: general at openid.net <mailto:general at openid.net>
>     Subject: Re: [OpenID] Too many providers... and here's one reason
>
>
>     On 15-Sep-08, at 4:45 PM, Andrew Arnott 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.
>
>     I have envisioned this as a chain of assertions / claims.
>
>     The user has a claim that their identifier is a member of the org.
>     This claim could be cached or obtained each time it is needed.
>
>     The user then presents that claim (binding identifier to org
>     membership) and also proves that they control the identifier presented
>     to the RP.
>
>     InfoCards has this flow speced out ... will be interesting to see if
>     there is interest in this from the OpenID community, particularly
>     since this is where the identity  protocols really  start to
>     differentiate themselves from existing username/password and form fill.
>
>     -- Dick
>
>     _______________________________________________
>     general mailing list
>     general at openid.net <mailto:general at openid.net>
>     http://openid.net/mailman/listinfo/general
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general