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

Tue Sep 16 16:20:04 UTC 2008

Sorry to change the subject a little... I'm new to this list and to
the whole OpenID concept. I am having trouble following the
conversation because of the number of TLAs that are being thrown
about. I'm not asking that anyone change, of course... but is there a
decent glossary of these terms out there for a newbie?

Thanks!

-Kelly

On Tue, Sep 16, 2008 at 10:13 AM, George Fletcher <gffletch at aol.com> wrote:
> Great points about PKI and best practices. +1 for a 'standard way' to do
> it:)
>
> Full XRDS allows for the inclusion of public keys and signing the XRDS
> document... so that would be one path. It could also be that the ORG
> asserting membership would publish it's public key is a well known
> location. In SAML this data is included in the SAML metadata document.
>
> Also, Patrick Harding from Ping Identity has suggested signing the
> document containing the public key and then allowing the RP to use the
> cert chain to determine if the document is valid within it's context or
> not (realizing that in some cases these deployments will be within
> closed circles of trust).
>
> I do think that Shade's comment about revocation of membership is a good
> one. These 3rd-party attested attributes need an expiration time. Also,
> the update mechanism of AX should allow the attesting party to update
> the attribute at the user's preferred OP if the membership changes.
> Though that requires both parties to support the update mechanism.
>
> Thanks,
> George
>
>
> Dick Hardt wrote:
>> One way of getting the public key would be to include it in the
>> assertion and have the cert signed by a higher, trusted party.
>> (typical PKI)
>>
>> Unless you use the existing PKI, I don't know of a best practice for
>> binding domains/URLs to public keys. (there are lots of ways to do it,
>> but what is "best practice"?)
>>
>> Personally, I'd like to see a 'standard way' to do it in OpenID that
>> did NOT use existing PKI. Then we could use PK crypto
>> for verifying OpenID message signatures and move away from managing
>> pair wise keys between RP and OP. Currently this is a pipe dream of
>> course. :-)
>>
>> -- Dick
>>
>> On 16-Sep-08, at 8:22 AM, Andrew Arnott wrote:
>>
>>> I just love a good topic to get the creative juices flowing from so
>>> many brainy people.  Thanks all for your ideas.
>>>
>>> Regarding George's OP identity assertion w/ AX membership
>>> attribute... How could Org XYZ sign the attribute so that coming from
>>> some OP it would be a verifiable?  Regarding this loose trust
>>> relationship between the OP and Org XYZ, what would that constitute?
>>>
>>> The few RPs that would be interested in my membership can have
>>> specially crafted AX fetch requests, no problem.  But these RPs need
>>> to be able to work against whatever OP the authenticating user
>>> happens to choose.  If only a few OPs might support these signed AX
>>> attributes that's fine, as long as the user has a choice and there is
>>> no strong affiliation between OP, RP and Org.
>>>
>>> I wonder if Org could assert my membership with a signed, encoded
>>> string, including my claimed id whatever that may be, and I take that
>>> encoded string and AX-store it myself to my arbitrary OP.  Then any
>>> AX-fetch (with my permission) would retrieve that and the RP could
>>> check the signature.  The only thing remaining in my mind is how the
>>> RP could verify the signature.  Can an ordinary public HTTPS server
>>> cert on Org.com be used to verify a signature if it is signed the
>>> right way?  Or is there some other way to do that?
>>>
>>> On Tue, Sep 16, 2008 at 6:26 AM, George Fletcher <gffletch at aol.com
>>> <mailto:gffletch at aol.com>> wrote:
>>>
>>>     Per Dick's response earlier in the thread, I don't see why using
>>>     an OP of my choice with a third party asserted attribute of my
>>>     membership in org XYZ isn't sufficient to meet this use case.
>>>
>>>     Basically, I'd use my preferred OP and request the organization
>>>     to provide a signed attribute of my membership in org XYZ. Then
>>>     when I log into the RP (with the OP of my choice), it can request
>>>     this attribute and I can choose to provide it (or not) at time of
>>>     authentication.
>>>
>>>     This should be completely doable with the existing OpenID 2.0 and
>>>     Attribute Exchange specs. Is the issue what Peter mentioned that
>>>     there aren't many AX supporters right now?
>>>
>>>     Of course, there will have to be a "trust relationship" between
>>>     org XYZ and my preferred OP, but I don't see that trust as any
>>>     deeper than the "trust relationship" between and RP and an OP.
>>>
>>>     Thanks,
>>>     George
>>>
>>>     Andrew Arnott wrote:
>>>
>>>         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>
>>>         <mailto: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 <mailto:andrewarnott at gmail.com>
>>>            <http://andrewarnott@gmail.com <http://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.
>>>
>>>
>>>         ------------------------------------------------------------------------
>>>
>>>         _______________________________________________
>>>         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 <mailto:general at openid.net>
>>> http://openid.net/mailman/listinfo/general
>>
>> =
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>