[OpenID] Too many providers... and here's one reason
George Fletcher
gffletch at aol.com
Tue Sep 16 16:13:35 UTC 2008
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
>
> =
More information about the general
mailing list