[OpenID] Too many providers... and here's one reason
Johannes Ernst
jernst+openid.net at netmesh.us
Sat Sep 20 22:17:03 UTC 2008
We are miscommunicating here. You are making a security argument, and
I'm making a software architecture argument.
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
>>
More information about the general
mailing list