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

Ben Laurie benl at google.com
Sat Sep 20 22:24:58 UTC 2008 

On Sat, Sep 20, 2008 at 3:17 PM, Johannes Ernst
<jernst+openid.net at netmesh.us> wrote:
> We are miscommunicating here. You are making a security argument, and
> I'm making a software architecture argument.

No. I am saying that if the user experience is not to change then you
are severely restricted in what you can do.

>
> On Sep 20, 2008, at 7:38 , Ben Laurie wrote:
>
>> On Tue, Sep 16, 2008 at 2:45 PM, Johannes Ernst
>> <jernst+openid.net at netmesh.us> wrote:
>>> There is one gigantic thing that people tend to overlook when making
>>> sweeping statements such as "... cannot ever ..." about OpenID.
>>>
>>> Which is that by virtue of Yadis / XRDS / XRDS-Simple / whatever-its-
>>> called-these-days, it is pluggable.
>>>
>>> So you can define your own authentication protocol, and it plugs
>>> right
>>> in, with *no* change in user experience. (Just like we've been LID
>>> GPG-
>>> based authentication alongside OpenID Auth just fine, thank you)
>>
>> a) That's equivalent to saying that all auth has the same UI, which is
>> clearly untrue (or we'd all be using client certs and openid would
>> never have been invented)
>>
>> b) If you are allowed to vary the UI then all auth protocols are
>> pluggable.
>>
>>>
>>> So: if there are requirements that OpenID Auth in its current version
>>> does not address,
>>> and: you have made a proposal how to fix it and got shot down,
>>> then: you do it anyway, call it BetterAuth or whatever, and drum the
>>> market up to support it. After all, if it is such a glaring gigantic
>>> problem, the market will immediately agree with you, and everybody
>>> will implement it immediately, right?
>>>
>>> Peter -- my apologies, I do not mean to attack you personally at all.
>>> I'm making a more sweeping statement ;-) and you are just a
>>> convenient
>>> victim ;-)
>>>
>>>
>>>
>>> On Sep 16, 2008, at 14:27 , Peter Williams wrote:
>>>
>>>> Folks in the liberty alliance message (openly and convincingly)
>>>> that openid cannot ever - inherently - be used for any purpose
>>>> requiring "assurance". They point to the  undisputed claim that the
>>>> open designers knowingly made design tradeoffs in the crypto
>>>> handshake and security critical securty service composition rules,
>>>> so as to make it all easy to deploy and adopt. Because of this
>>>> precept, openid cannot even *be* fixed (since low assurance is the
>>>> actual goal).
>>>>
>>>> This relegates openid to business needs that really cannot benefit
>>>> from membership secrecy or strong auth - since it doesn't aim to
>>>> provide for these today, or even in the future.
>>>>
>>>> Sigh. Cannot use it, and cannot fix it. Meantime, only choice is to
>>>> use openid competition: saml/wsfed/wstrust (high end) or oauth
>>>> (really low end).
>>>>
>>>> Doenst this seem a frustrating position to take, or accept?
>>>>
>>>> -----Original Message-----
>>>> From: Tatsuki Sakushima <tatsuki at nri.com>
>>>> Sent: Tuesday, September 16, 2008 10:31 AM
>>>> To: Peter Williams <pwilliams at rapattoni.com>
>>>> Cc: Andrew Arnott <andrewarnott at gmail.com>; general at openid.net <general at openid.net
>>>>>
>>>> Subject: Re: [OpenID] Too many providers... and here's one reason
>>>>
>>>>
>>>> Mixi's use case is a casual one. Their membership authentication
>>>> will be
>>>> used for filtering who can comment user's blog based on whether
>>>> visitors
>>>> are user's friend or a member of specific groups. (Mixi is in a good
>>>> position to provide this kind of information.)
>>>>
>>>> The use case of this topic is a business case. When OP plays a
>>>> important
>>>> role behalf of its users such as managing membership information to
>>>> many
>>>> different channels, I think that assurance is a key to make this
>>>> happen.
>>>>
>>>> If OP can have trustworthiness backed up by an assurance program,
>>>> RPs
>>>> can engage users directly through OP. Nat's Trusted Exchange spec is
>>>> one
>>>> way to create this information back channel behind OP.
>>>>
>>>> I started the discussion to make PAPE assurance program ready in the
>>>> WG.
>>>> Please join us if interested.
>>>>
>>>> Tatsuki Sakushima
>>>> NRI Pacific - Nomura Research Institute America, Inc.
>>>>
>>>> Peter Williams さんは書きました:
>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> general at openid.net
>>>> http://openid.net/mailman/listinfo/general
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>

More information about the general mailing list