[OpenID] Too many providers... and here's one reason
Johannes Ernst
jernst+openid.net at netmesh.us
Tue Sep 16 22:30:10 UTC 2008
You are making my point: there has been little technical work, and
that seems to indicate that the current tech does what adopters want
it to do. There are plenty of people on this list who understand the
issues and could construct the tech in a heartbeat, so that can't be it.
(Says me, who still likes GPG better than symmetric secrets)
In any case, 99% that I've ever heard and that starts with "OpenID ...
cannot ever ..." is wrong because of the pluggability aspect, and that
was my point.
On Sep 16, 2008, at 14:57 , Dick Hardt wrote:
> Johannes
>
> Not to be nit picky, but what if discovery is part of the perceived
> problem? Then there is no XRDS.
>
> Market perceptions of a technology are people's reality, regardless
> of what is possible with the technology.
>
> While there is the potential to move OpenID technology to be
> "stronger", there has been little technical work to make that happen
> to date.
>
> -- Dick
>
> On 16-Sep-08, at 2:45 PM, Johannes Ernst 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)
>>
>> 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
>
Johannes Ernst
NetMesh Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-relying-party-anonymous.gif
Type: image/gif
Size: 903 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080916/b273cd39/attachment-0004.gif>
-------------- next part --------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 977 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080916/b273cd39/attachment-0005.gif>
-------------- next part --------------
http://netmesh.info/jernst
More information about the general
mailing list