[OpenID] TLAs
Dick Hardt
dick.hardt at gmail.com
Tue Sep 16 16:36:25 UTC 2008
List the ones you don't know on this thread and we can define them.
-- Dick
On 16-Sep-08, at 9:20 AM, Kelly Anderson wrote:
> 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
>>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
More information about the general
mailing list