[OpenID] Too many providers and here's one reason
Nat Sakimura
n-sakimura at nri.co.jp
Thu Oct 30 02:28:27 UTC 2008
openid.ee is doing conceptually similar thing: i.e., third party
asserted attirbute, in their case, national ID system (eID).
Thrid party assertion is useful in other context as well such as thrid
party assurance.
Are you going to create a WG for it?
=nat
santosh subramanian wrote:
> Hi,
>
> We've been working on a similar problem where Org XYZ needs to verify
> certain claims about the end user. For example, a dating site might
> need to verify a user's age before letting them log in. In our
> solution, one party, which we call the Attribute Provider (AP), provides
> a signed certificate that the the user possesses some attribute (e.g.
> is over 18). This certificate is stored as an attribute at the user's
> OP, and other RPs can request this certificate when they want to
> verify attributes of the user.
> For the implementation, we have followed the OpenID Signed Assertions
> draft: http://www.mail-archive.com/specs@openid.net/msg00907.html
>
> The Signed Assertions Draft did not specify how signed assertions are
> stored at the OP, so we adopted the following scheme:
> Attribute: http://X <http://x/>
> Certificate: http://X/signature <http://x/signature>
> This enables RPs that don't care about certificates to completely
> ignore them. Assertions are SAML documents as specified in the OpenID
> Signed
> Assertions old draft.
> We are developing a demo application in which a university issues
> certificates verifying students' age, student-hood, and even their
> photo (also potentially useful to dating sites). So basically the
> university acts as an attribute provider, signing assertions about
> user claims. These claims are stored as an attribute in the OpenId
> provider and we can use the OpenID AX protocol to pass assertions as
> attributes. The data flow is:
> User requests assertion --- University(Attribute provider)
> --- (store request)
> --- Openid provider
> Relying Party(Dating site) --- (fetch request) --- OpenID Provider
> The RP gets the assertion, verifies the signature, and takes actions
> depending on the result. In some scenarios, the RP may deny the user
> request if the attribute verification fails (e.g. the dating site may
> forbid users under 18). In other scenarios the RP may treat them
> differently (e.g. the dating site could tag certified photos as
> "Verified Photo").
> Note that the RP must have some sort of trust relationship with the
> AP. We've tried to keep the system as open as possible. Our protocol
> and implementation do not specify how this trust relationship is
> created or managed. For example, there could be a PKI specifically
> set up for verifying claims about student-hood, another trust system
> set up for verifying claims about age, etc.
>
> Best Regards,
>
> Santosh Subramanian
> Shishir Randive
> Michael Hart
> Rob Johnson
>
> > On Tue, Sep 16, 2008 at 10:13 AM, George Fletcher
> <gffletch at aol.com <mailto: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>
> >>>> <mailto: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>>
> >>>> <mailto: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> <mailto:andrewarnott at gmail.com
> <mailto:andrewarnott at gmail.com>>
> >>>> <http://andrewarnott
> <http://andrewarnott/>@gmail.com <http://gmail.com/>
> <http://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>
> <mailto: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>
> <mailto: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 <mailto:general at openid.net>
> > http://openid.net/mailman/listinfo/general
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 16 Sep 2008 09:46:26 -0700
> From: Peter Williams <pwilliams at rapattoni.com
> <mailto:pwilliams at rapattoni.com>>
> Subject: Re: [OpenID] Too many providers... and here's one reason
> To: Dick Hardt <dick.hardt at gmail.com
> <mailto:dick.hardt at gmail.com>>, Andrew Arnott
> <andrewarnott at gmail.com <mailto:andrewarnott at gmail.com>>
> Cc: "general at openid.net <mailto:general at openid.net>"
> <general at openid.net <mailto:general at openid.net>>
> Message-ID:
>
> <7FD5B754D66D9A489C584ECA4B32418F20F08F92 at simmbox01.rapnt.com
> <mailto:7FD5B754D66D9A489C584ECA4B32418F20F08F92 at simmbox01.rapnt.com>>
> Content-Type: text/plain; charset="us-ascii"
>
> So I hear infocard folks noting that claims can be tansformed by a
> cascade of sts (each of which add increasingly rp centric value,
> perhaps testing for membership agin some db).
>
> Had not heard the notion of there being a set of assertions in the
> core model, however, or a chain of assertions. Such would
> obligates the rp to start doing (complex) path processing, of
> course like certs or ospf spf math.
>
> Might aswell use x509 pacs and dynamic pac issuing, at this point.
> Standard already exists. One could serialize the asn.1 pacs in xml
> if one wants, rather than binary. The core standard doesn't
> (really) care about bit formats, so long a canocialization issues
> are addressed (by such as xml dsig). Pacs aleady work fine in ssl
> (via the saml wrapper in the client auth msg of tls 1.2)
>
> -----Original Message-----
> From: Dick Hardt <dick.hardt at gmail.com <mailto:dick.hardt at gmail.com>>
> Sent: Tuesday, September 16, 2008 8:49 AM
> To: Andrew Arnott <andrewarnott at gmail.com
> <mailto:andrewarnott at gmail.com>>
> Cc: Peter Williams <pwilliams at rapattoni.com
> <mailto:pwilliams at rapattoni.com>>; general at openid.net
> <mailto:general at openid.net> <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 6:06 PM, Andrew Arnott wrote:
>
> > You know on second thought, perhaps OAuth is appropriate. The
> > 'protected resource' in this case is my membership status. And
> > while creating my account at the RP, I can check a box saying "you
> > may check my membership at org xyz", which will cue the RP that it's
> > worthwhile to redirect me to that site using OAuth to verify
> > membership.
>
> This works if the RP knows the address of where to check for
> membership status. A more resilient and flexible model separates the
> claim from where to get the claim so that the RP does not care where
> the claim comes from, just that it got the claim.
>
> Frankly, InfoCards solve your problem better then OAuth and OpenID
> today.
>
> -- Dick
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 16 Sep 2008 10:31:01 -0700
> From: Tatsuki Sakushima <tatsuki at nri.com <mailto:tatsuki at nri.com>>
> Subject: Re: [OpenID] Too many providers... and here's one reason
> To: Peter Williams <pwilliams at rapattoni.com
> <mailto:pwilliams at rapattoni.com>>
> Cc: "general at openid.net <mailto:general at openid.net>"
> <general at openid.net <mailto:general at openid.net>>
> Message-ID: <48CFED55.60609 at nri.com <mailto:48CFED55.60609 at nri.com>>
> Content-Type: text/plain; charset=UTF-8
>
> 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 <mailto:tatsuki at nri.com>>
> > Sent: Monday, September 15, 2008 10:39 PM
> > To: Andrew Arnott <andrewarnott at gmail.com
> <mailto:andrewarnott at gmail.com>>
> > Cc: Peter Williams <pwilliams at rapattoni.com
> <mailto:pwilliams at rapattoni.com>>; general at openid.net
> <mailto:general at openid.net> <general at openid.net
> <mailto: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>
> >> <mailto: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>>
> >> [mailto: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>
> <mailto: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>
> <mailto: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
> >
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 16 Sep 2008 11:11:27 -0700
> From: "Eric Sachs" <esachs at google.com <mailto:esachs at google.com>>
> Subject: Re: [OpenID] Too many providers... and here's one reason
> To: "SitG Admin" <sysadmin at shadowsinthegarden.com
> <mailto:sysadmin at shadowsinthegarden.com>>
> Cc: general at openid.net <mailto:general at openid.net>
> Message-ID:
>
> <c4161f510809161111s5fc4bbffge4da5fbbc12f7750 at mail.gmail.com
> <mailto:c4161f510809161111s5fc4bbffge4da5fbbc12f7750 at mail.gmail.com>>
> Content-Type: text/plain; charset="iso-8859-1"
>
> In the OAuth space there are a bunch of companies/projects doing
> something
> that they term differently, but which sounds very similar to your
> use case.
>
> An OAuth "aggregator" wants to pull together assertions about a
> particular
> user (call him Tom) from multiple 3rd parties, and then allow Tom
> to share
> those assertions with other users of the aggregator site, or share
> them to
> other 3rd party sites. The most well known examples are activity
> streams in
> OpenSocial, and personal health record stores like MS HealthVault
> & Google
> Health.
>
> Some examples of assertions includes things like "Stanford says
> this user
> graduated with a Comp Sci degree from Stanford," or "World of Warcraft
> says this user's warrior on World of Warcraft is level 33," or
> "LabQuest
> says this user had lab test X with result Y."
>
> In most of these scenarios, we are seeing that the downstream
> readers of an
> assertion are willing to trust the aggregator to specify the
> identity of the
> original asserter. That is not as cryptographically strong as the
> original
> source signing their assertion, however as people noted in this
> thread, it
> is certainly possible to add that feature. Though in some
> specialized cases
> the digital signatures can leak privacy details, and avoiding that
> requires
> even more advanced crypto techniques.
>
> If you want to learn more, there are some comments about this type of
> assertion "gathering" in the following two documents about how
> OAuth is
> used, however they are targeted more at product managers/marketing
> types,
> and don't focus much on the technical details.
>
> https://sites.google.com/site/oauthgoog/oauth-practices
>
> https://sites.google.com/site/oauthgoog/oauth-practices/user-interface
>
> Eric SachsProduct Manager, Google Security
>
> On Tue, Sep 16, 2008 at 8:23 AM, SitG Admin
> <sysadmin at shadowsinthegarden.com
> <mailto:sysadmin at shadowsinthegarden.com>
> > wrote:
>
> > >Basically, I'd use my preferred OP and request the organization to
> > >provide a signed attribute of my membership in org XYZ.
> >
> > Interesting thought - signed by the organization? Perhaps an
> > assertion of membership AND "here's what your organization gave
> us to
> > remind them that you are a member", so the organization can
> recognize
> > revoked membership signatures?
> >
> > >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.
> >
> > If there were only a single OP in the world, it would even be the
> > *same* trust relationship, and with one OP handling authentication
> > for several organizations; just as one OP can handle authentication
> > for more than a single organization now.
> >
> > But perhaps starting out as the OP for a small organization, at
> > first, can be an opportunity for new developers to both assure
> > themselves of OpenID's security and find gainful employment in
> > connection to business startups?
> >
> > -Shade
> > _______________________________________________
> > general mailing list
> > general at openid.net <mailto:general at openid.net>
> > http://openid.net/mailman/listinfo/general
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://openid.net/pipermail/general/attachments/20080916/796e90f6/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net <mailto:general at openid.net>
> http://openid.net/mailman/listinfo/general
>
>
> End of general Digest, Vol 25, Issue 27
> ***************************************
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
More information about the general
mailing list