<div>Hi,</div>
<div><br> We've been working on a similar problem where Org XYZ needs to verify<br>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<br>
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.</div>
<div>For the implementation, we have followed the OpenID Signed Assertions</div>
<div>draft: <a href="http://www.mail-archive.com/specs@openid.net/msg00907.html">http://www.mail-archive.com/specs@openid.net/msg00907.html</a></div>
<div><br>The Signed Assertions Draft did not specify how signed assertions are<br>stored at the OP, so we adopted the following scheme:<br> Attribute: <a href="http://x/">http://X</a><br> Certificate: <a href="http://x/signature">http://X/signature</a><br>
This enables RPs that don't care about certificates to completely ignore them. Assertions are SAML documents as specified in the OpenID Signed<br>Assertions old draft.</div>
<div>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:</div>
<div> User requests assertion --- University(Attribute provider)<br> --- (store request)<br> --- Openid provider<br> Relying Party(Dating site) --- (fetch request) --- OpenID Provider</div>
<div>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").</div>
<div>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.</div>
<div> </div>
<div>Best Regards,</div>
<div> </div>
<div>Santosh Subramanian</div>
<div>Shishir Randive</div>
<div>Michael Hart </div>
<div>Rob Johnson</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> On Tue, Sep 16, 2008 at 10:13 AM, George Fletcher <<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>><br>
> wrote:<br>>> Great points about PKI and best practices. +1 for a 'standard way'<br>>> to do<br>>> it:)<br>>><br>>> Full XRDS allows for the inclusion of public keys and signing the<br>
>> XRDS<br>>> document... so that would be one path. It could also be that the ORG<br>>> asserting membership would publish it's public key is a well known<br>>> location. In SAML this data is included in the SAML metadata<br>
>> document.<br>>><br>>> Also, Patrick Harding from Ping Identity has suggested signing the<br>>> document containing the public key and then allowing the RP to use<br>>> the<br>>> cert chain to determine if the document is valid within it's<br>
>> context or<br>>> not (realizing that in some cases these deployments will be within<br>>> closed circles of trust).<br>>><br>>> I do think that Shade's comment about revocation of membership is a<br>
>> good<br>>> one. These 3rd-party attested attributes need an expiration time.<br>>> Also,<br>>> the update mechanism of AX should allow the attesting party to update<br>>> the attribute at the user's preferred OP if the membership changes.<br>
>> Though that requires both parties to support the update mechanism.<br>>><br>>> Thanks,<br>>> George<br>>><br>>><br>>> Dick Hardt wrote:<br>>>> One way of getting the public key would be to include it in the<br>
>>> assertion and have the cert signed by a higher, trusted party.<br>>>> (typical PKI)<br>>>><br>>>> Unless you use the existing PKI, I don't know of a best practice for<br>>>> binding domains/URLs to public keys. (there are lots of ways to do<br>
>>> it,<br>>>> but what is "best practice"?)<br>>>><br>>>> Personally, I'd like to see a 'standard way' to do it in OpenID that<br>>>> did NOT use existing PKI. Then we could use PK crypto<br>
>>> for verifying OpenID message signatures and move away from managing<br>>>> pair wise keys between RP and OP. Currently this is a pipe dream of<br>>>> course. :-)<br>>>><br>>>> -- Dick<br>
>>><br>>>> On 16-Sep-08, at 8:22 AM, Andrew Arnott wrote:<br>>>><br>>>>> I just love a good topic to get the creative juices flowing from so<br>>>>> many brainy people. Thanks all for your ideas.<br>
>>>><br>>>>> Regarding George's OP identity assertion w/ AX membership<br>>>>> attribute... How could Org XYZ sign the attribute so that coming<br>>>>> from<br>>>>> some OP it would be a verifiable? Regarding this loose trust<br>
>>>> relationship between the OP and Org XYZ, what would that<br>>>>> constitute?<br>>>>><br>>>>> The few RPs that would be interested in my membership can have<br>>>>> specially crafted AX fetch requests, no problem. But these RPs<br>
>>>> need<br>>>>> to be able to work against whatever OP the authenticating user<br>>>>> happens to choose. If only a few OPs might support these signed AX<br>>>>> attributes that's fine, as long as the user has a choice and<br>
>>>> there is<br>>>>> no strong affiliation between OP, RP and Org.<br>>>>><br>>>>> I wonder if Org could assert my membership with a signed, encoded<br>>>>> string, including my claimed id whatever that may be, and I take<br>
>>>> that<br>>>>> encoded string and AX-store it myself to my arbitrary OP. Then any<br>>>>> AX-fetch (with my permission) would retrieve that and the RP could<br>>>>> check the signature. The only thing remaining in my mind is how<br>
>>>> the<br>>>>> RP could verify the signature. Can an ordinary public HTTPS server<br>>>>> cert on Org.com be used to verify a signature if it is signed the<br>>>>> right way? Or is there some other way to do that?<br>
>>>><br>>>>> On Tue, Sep 16, 2008 at 6:26 AM, George Fletcher <<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a><br>>>>> <mailto:<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>>> wrote:<br>
>>>><br>>>>> Per Dick's response earlier in the thread, I don't see why using<br>>>>> an OP of my choice with a third party asserted attribute of my<br>>>>> membership in org XYZ isn't sufficient to meet this use case.<br>
>>>><br>>>>> Basically, I'd use my preferred OP and request the organization<br>>>>> to provide a signed attribute of my membership in org XYZ. Then<br>>>>> when I log into the RP (with the OP of my choice), it can<br>
>>>> request<br>>>>> this attribute and I can choose to provide it (or not) at time<br>>>>> of<br>>>>> authentication.<br>>>>><br>>>>> This should be completely doable with the existing OpenID 2.0<br>
>>>> and<br>>>>> Attribute Exchange specs. Is the issue what Peter mentioned that<br>>>>> there aren't many AX supporters right now?<br>>>>><br>>>>> Of course, there will have to be a "trust relationship" between<br>
>>>> org XYZ and my preferred OP, but I don't see that trust as any<br>>>>> deeper than the "trust relationship" between and RP and an OP.<br>>>>><br>>>>> Thanks,<br>
>>>> George<br>>>>><br>>>>> Andrew Arnott wrote:<br>>>>><br>>>>> You're affirmative action example is well taken. Obviously<br>>>>> if an OP is the best solution we should go with it. But<br>
>>>> just<br>>>>> imagine what all these spoons of sugar are going to do to<br>>>>> me...<br>>>>><br>>>>> Suppose I'm a member of 15 organizations (that's<br>
>>>> conservative) between my professional, social, personal<br>>>>> lives. Some RP could be interested in providing specialized<br>>>>> services if I am a member of Org XYZ. Another RP may offer<br>
>>>> premium services if I am a member of Org ABC.<br>>>>><br>>>>> Now if every org I am a member of became an OP, then my<br>>>>> identity XRDS file now has at least 15 providers listed.<br>
>>>> Powerful, perhaps. Dangerous: yes!!! If OpenID's weakness<br>>>>> already was that if an OP was compromised then all<br>>>>> Identifiers that allow that OP's assertions are now<br>
>>>> compromised, then that weakness is proportional to the<br>>>>> number<br>>>>> of OPs that are listed in my XRDS file. I for one do NOT<br>>>>> want 15 Providers listed in my XRDS file. There was a<br>
>>>> time I<br>>>>> thought more was better, and to date I have some 5-6 OPs<br>>>>> listed, but I've considered narrowing that down to just 2-3<br>>>>> to decrease my risk surface area.<br>
>>>><br>>>>> Using OAuth as a post-authentication step of confirming<br>>>>> membership is an interesting idea and should work. In the<br>>>>> end, whether we use OpenID or OAuth, it seems we're mixing<br>
>>>> authentication and membership, or authorization and<br>>>>> membership, in order to just get membership. Too bad<br>>>>> there's<br>>>>> not just a way to get "membership".<br>
>>>><br>>>>> Yes, InfoCard managed cards solve this problem, although not<br>>>>> as implicitly as I'd like. I'm hoping OpenID can have a<br>>>>> solution of its own.<br>
>>>><br>>>>> On Mon, Sep 15, 2008 at 5:12 PM, Eran Hammer-Lahav<br>>>>> <<a href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a> <mailto:<a href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a>><br>
>>>> <mailto:<a href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a> <mailto:<a href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a>>>><br>>>>> wrote:<br>
>>>><br>>>>> This is like applying affirmative action to cooking.<br>>>>> "This<br>>>>> cake<br>>>>> calls for two spoons of sugar but we don't have enough<br>
>>>> people<br>>>>> using lard in cakes, so I am going to use it instead..."<br>>>>><br>>>>> Looks like they want to use OpenID as an assertion<br>>>>> verification<br>
>>>> protocol, allowing them to confirm that a given user is<br>>>>> in<br>>>>> fact a<br>>>>> member of their organization. If all they want to do is<br>
>>>> assert the<br>>>>> claim, they can use both OAuth and OpenID, each with a<br>>>>> different<br>>>>> set of extra features. If they use OpenID, a side-effect<br>
>>>> of this<br>>>>> will turn them into an Identity Provider, but if this is<br>>>>> not their<br>>>>> intention, they should not use that identifier<br>
>>>> internally, but<br>>>>> instead accept OpenID.<br>>>>><br>>>>> In other words, they should be an OP for assertion<br>>>>> verification,<br>
>>>> and RP for site login.<br>>>>><br>>>>> EHL<br>>>>><br>>>>><br>>>>><br>>>>> On 9/15/08 4:45 PM, "Andrew Arnott"<br>
>>>> <<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a> <mailto:<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>><br>>>>> <<a href="http://andrewarnott/" target="_blank">http://andrewarnott</a>@<a href="http://gmail.com/" target="_blank">gmail.com</a> <<a href="http://gmail.com/" target="_blank">http://gmail.com</a>>>><br>
>>>> wrote:<br>>>>><br>>>>> I just spoke with an organization that wants to<br>>>>> become a<br>>>>> Provider so that other RP web sites can specifically<br>
>>>> tell if<br>>>>> the logging in user is a member of this<br>>>>> organization by<br>>>>> whether their OpenID Identifier was asserted by that<br>
>>>> org's OP.<br>>>>> Ideally, I'd like this org to choose to be an RP<br>>>>> instead of an<br>>>>> OP because there are already too many OPs out there<br>
>>>> and not<br>>>>> enough RPs, IMO.<br>>>>> How can an RP accept an OpenID Identifier from<br>>>>> arbitrary OPs,<br>>>>> but at each login determine whether the Identifier<br>
>>>> represents<br>>>>> a user who belongs to a particular Organization?<br>>>>> Basically<br>>>>> the Organization needs to send an assertion about the<br>
>>>> Identifier's membership, but only be willing to do so<br>>>>> if that<br>>>>> identifier is confirmed as having logged in<br>>>>> successfully to<br>
>>>> that RP. This would be easy to do if that Org was an<br>>>>> OP, but<br>>>>> I'm trying to reduce the # of reasons to be an OP.<br>>>>><br>
>>>><br>>>>><br>>>>> ------------------------------------------------------------------------<br>>>>><br>>>>> _______________________________________________<br>
>>>> general mailing list<br>>>>> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
>>>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>>>>><br>>>>><br>>>>><br>>>>><br>
>>>> _______________________________________________<br>>>>> general mailing list<br>>>>> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
>>>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>>>><br>>>> =<br>>><br>>> _______________________________________________<br>
>> general mailing list<br>>> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
>><br>> _______________________________________________<br>> general mailing list<br>> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 16 Sep 2008 09:46:26 -0700<br>From: Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><br>
Subject: Re: [OpenID] Too many providers... and here's one reason<br>To: Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>>, Andrew Arnott<br> <<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>><br>
Cc: "<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>" <<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>Message-ID:<br> <<a href="mailto:7FD5B754D66D9A489C584ECA4B32418F20F08F92@simmbox01.rapnt.com" target="_blank">7FD5B754D66D9A489C584ECA4B32418F20F08F92@simmbox01.rapnt.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br><br>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).<br>
<br>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.<br>
<br>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)<br>
<br>-----Original Message-----<br>From: Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>><br>Sent: Tuesday, September 16, 2008 8:49 AM<br>To: Andrew Arnott <<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>><br>
Cc: Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>>; <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
Subject: Re: [OpenID] Too many providers... and here's one reason<br><br><br>On 15-Sep-08, at 6:06 PM, Andrew Arnott wrote:<br><br>> You know on second thought, perhaps OAuth is appropriate. The<br>> 'protected resource' in this case is my membership status. And<br>
> while creating my account at the RP, I can check a box saying "you<br>> may check my membership at org xyz", which will cue the RP that it's<br>> worthwhile to redirect me to that site using OAuth to verify<br>
> membership.<br><br>This works if the RP knows the address of where to check for<br>membership status. A more resilient and flexible model separates the<br>claim from where to get the claim so that the RP does not care where<br>
the claim comes from, just that it got the claim.<br><br>Frankly, InfoCards solve your problem better then OAuth and OpenID<br>today.<br><br>-- Dick<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 16 Sep 2008 10:31:01 -0700<br>
From: Tatsuki Sakushima <<a href="mailto:tatsuki@nri.com" target="_blank">tatsuki@nri.com</a>><br>Subject: Re: [OpenID] Too many providers... and here's one reason<br>To: Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><br>
Cc: "<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>" <<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>Message-ID: <<a href="mailto:48CFED55.60609@nri.com" target="_blank">48CFED55.60609@nri.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br><br>Mixi's use case is a casual one. Their membership authentication will be<br>used for filtering who can comment user's blog based on whether visitors<br>are user's friend or a member of specific groups. (Mixi is in a good<br>
position to provide this kind of information.)<br><br>The use case of this topic is a business case. When OP plays a important<br>role behalf of its users such as managing membership information to many<br>different channels, I think that assurance is a key to make this happen.<br>
<br>If OP can have trustworthiness backed up by an assurance program, RPs<br>can engage users directly through OP. Nat's Trusted Exchange spec is one<br>way to create this information back channel behind OP.<br><br>I started the discussion to make PAPE assurance program ready in the WG.<br>
Please join us if interested.<br><br>Tatsuki Sakushima<br>NRI Pacific - Nomura Research Institute America, Inc.<br><br>Peter Williams ????????:<br>> 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?<br>
><br>> 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.<br>
><br>> Without a formal signature (like in xri) its hard to do much better with openid1.<br>><br>> -----Original Message-----<br>> From: Tatsuki Sakushima <<a href="mailto:tatsuki@nri.com" target="_blank">tatsuki@nri.com</a>><br>
> Sent: Monday, September 15, 2008 10:39 PM<br>> To: Andrew Arnott <<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>><br>> Cc: Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>>; <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
> Subject: Re: [OpenID] Too many providers... and here's one reason<br>><br>><br>> Mixi, the largest SNS in Japan, does membership authentication in a<br>> simple manner. They just let RPs specifiy URL of OP that users should<br>
> have membership. However, this way won't reduce the number of OPs that<br>> users have to manage even thought it is straight forward and easy to<br>> understand.<br>><br>> I think that having a master OP to manage all other OPs that users have<br>
> membership with. But users must manage the list somehow. From users'<br>> perspective, I don't know which is a better way to do it.<br>><br>> Another way to think this is that RPs should consider they engage<br>
> directly to users through OPs with certain conditions such as providing<br>> information that RPs require. We also should think about purposes of<br>> membership. Do they have to belong to organizations that RPs specify to<br>
> get a deal?<br>><br>> Tatsuki Sakushima<br>> NRI Pacific - Nomura Research Institute America, Inc.<br>><br>> Andrew Arnott ????????:<br>>> That's sounding like what I was hoping existed.<br>>><br>
>> Now, since I'm hoping to separate authentication from this membership<br>>> test, and if I didn't want my membership in Org XYZ to be public<br>>> knowledge, from a user's perspective it seems the only way to get this<br>
>> to work would be this:<br>>><br>>> 1. I log into RP using an Identifier of my choice, and an asserting<br>>> OP of my choice<br>>> 2. The RP is interested in my membership in Org XYZ, so it asks Org<br>
>> XYZ if my Identifier is a member of the org.<br>>> 3. Similar to OpenID OP's list of sites I trust, Org XYZ checks if<br>>> the requesting RP is trusted by me. If it is, then it just<br>
>> answers yes. If not, it tells the RP to take the long route.<br>>> 4. The long route would be the RP redirecting me to Org XYZ to go to<br>>> a page where I would grant permission for the RP to find out that<br>
>> I am a member.<br>>> 5. The redirect (like OpenId) would tell the RP that I am in a<br>>> confirmable way.<br>>><br>>> Blah, that sounds way just like the org being an OP. So maybe for<br>
>> purposes of this investigation we'll just say it can be public<br>>> knowledge, but confirmable the way Peter just described.<br>>><br>>> On Mon, Sep 15, 2008 at 5:30 PM, Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><br>
>> <mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>>> wrote:<br>>><br>>> Couldn't this be handled by the XRI support, in the openid 2 world?<br>
>><br>>> Doesn't the XRI resolver allow the organizational claim to be tested?<br>>><br>>> XRI essentially has a yellow-pages resolver built in. For any yellow<br>>> page index, you can resolve a name via that particular naming path.<br>
>> The XRI resolver thus tests that one is listed in a particular<br>>> "organizational" index, or which there can be n. In trusted XRI,<br>>> furthermore, the SAML assertions would provide additional proof that<br>
>> the particular resolver listener is authorized to speak for those<br>>> organizations. In the HXRI trusted resolver variety, the usual trick<br>>> of the proxy resolver having n*1000 SSL server, one per<br>
>> organization, would be sufficient to know that the listener speaks<br>>> for the organization (over https)<br>>><br>>> -----Original Message-----<br>>> From: <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a> <mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>><br>
>> [mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a><br>>> <mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>>] On Behalf Of Dick Hardt<br>
>> Sent: Monday, September 15, 2008 5:12 PM<br>>> To: Andrew Arnott<br>>> Cc: <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>
>> Subject: Re: [OpenID] Too many providers... and here's one reason<br>>><br>>><br>>> On 15-Sep-08, at 4:45 PM, Andrew Arnott wrote:<br>>><br>>> > I just spoke with an organization that wants to become a Provider so<br>
>> > that other RP web sites can specifically tell if the logging in user<br>>> > is a member of this organization by whether their OpenID Identifier<br>>> > was asserted by that org's OP.<br>
>> ><br>>> > Ideally, I'd like this org to choose to be an RP instead of an OP<br>>> > because there are already too many OPs out there and not enough RPs,<br>>> > IMO.<br>
>> ><br>>> > How can an RP accept an OpenID Identifier from arbitrary OPs, but at<br>>> > each login determine whether the Identifier represents a user who<br>>> > belongs to a particular Organization? Basically the Organization<br>
>> > needs to send an assertion about the Identifier's membership, but<br>>> > only be willing to do so if that identifier is confirmed as having<br>>> > logged in successfully to that RP. This would be easy to do if that<br>
>> > Org was an OP, but I'm trying to reduce the # of reasons to be an OP.<br>>><br>>> I have envisioned this as a chain of assertions / claims.<br>>><br>>> The user has a claim that their identifier is a member of the org.<br>
>> This claim could be cached or obtained each time it is needed.<br>>><br>>> The user then presents that claim (binding identifier to org<br>>> membership) and also proves that they control the identifier presented<br>
>> to the RP.<br>>><br>>> InfoCards has this flow speced out ... will be interesting to see if<br>>> there is interest in this from the OpenID community, particularly<br>>> since this is where the identity protocols really start to<br>
>> differentiate themselves from existing username/password and form fill.<br>>><br>>> -- Dick<br>>><br>>> _______________________________________________<br>>> general mailing list<br>
>> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br>>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
>><br>>><br>>><br>>> ------------------------------------------------------------------------<br>>><br>>> _______________________________________________<br>>> general mailing list<br>
>> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>><br>
<br><br>------------------------------<br><br>Message: 4<br>Date: Tue, 16 Sep 2008 11:11:27 -0700<br>From: "Eric Sachs" <<a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a>><br>Subject: Re: [OpenID] Too many providers... and here's one reason<br>
To: "SitG Admin" <<a href="mailto:sysadmin@shadowsinthegarden.com" target="_blank">sysadmin@shadowsinthegarden.com</a>><br>Cc: <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
Message-ID:<br> <<a href="mailto:c4161f510809161111s5fc4bbffge4da5fbbc12f7750@mail.gmail.com" target="_blank">c4161f510809161111s5fc4bbffge4da5fbbc12f7750@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br>
<br>In the OAuth space there are a bunch of companies/projects doing something<br>that they term differently, but which sounds very similar to your use case.<br><br>An OAuth "aggregator" wants to pull together assertions about a particular<br>
user (call him Tom) from multiple 3rd parties, and then allow Tom to share<br>those assertions with other users of the aggregator site, or share them to<br>other 3rd party sites. The most well known examples are activity streams in<br>
OpenSocial, and personal health record stores like MS HealthVault & Google<br>Health.<br><br>Some examples of assertions includes things like "Stanford says this user<br>graduated with a Comp Sci degree from Stanford," or "World of Warcraft<br>
says this user's warrior on World of Warcraft is level 33," or "LabQuest<br>says this user had lab test X with result Y."<br><br>In most of these scenarios, we are seeing that the downstream readers of an<br>
assertion are willing to trust the aggregator to specify the identity of the<br>original asserter. That is not as cryptographically strong as the original<br>source signing their assertion, however as people noted in this thread, it<br>
is certainly possible to add that feature. Though in some specialized cases<br>the digital signatures can leak privacy details, and avoiding that requires<br>even more advanced crypto techniques.<br><br>If you want to learn more, there are some comments about this type of<br>
assertion "gathering" in the following two documents about how OAuth is<br>used, however they are targeted more at product managers/marketing types,<br>and don't focus much on the technical details.<br><br><a href="https://sites.google.com/site/oauthgoog/oauth-practices" target="_blank">https://sites.google.com/site/oauthgoog/oauth-practices</a><br>
<br><a href="https://sites.google.com/site/oauthgoog/oauth-practices/user-interface" target="_blank">https://sites.google.com/site/oauthgoog/oauth-practices/user-interface</a><br><br>Eric SachsProduct Manager, Google Security<br>
<br>On Tue, Sep 16, 2008 at 8:23 AM, SitG Admin <<a href="mailto:sysadmin@shadowsinthegarden.com" target="_blank">sysadmin@shadowsinthegarden.com</a><br>> wrote:<br><br>> >Basically, I'd use my preferred OP and request the organization to<br>
> >provide a signed attribute of my membership in org XYZ.<br>><br>> Interesting thought - signed by the organization? Perhaps an<br>> assertion of membership AND "here's what your organization gave us to<br>
> remind them that you are a member", so the organization can recognize<br>> revoked membership signatures?<br>><br>> >Of course, there will have to be a "trust relationship" between org XYZ<br>
> >and my preferred OP, but I don't see that trust as any deeper than the<br>> >"trust relationship" between and RP and an OP.<br>><br>> If there were only a single OP in the world, it would even be the<br>
> *same* trust relationship, and with one OP handling authentication<br>> for several organizations; just as one OP can handle authentication<br>> for more than a single organization now.<br>><br>> But perhaps starting out as the OP for a small organization, at<br>
> first, can be an opportunity for new developers to both assure<br>> themselves of OpenID's security and find gainful employment in<br>> connection to business startups?<br>><br>> -Shade<br>> _______________________________________________<br>
> general mailing list<br>> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://openid.net/pipermail/general/attachments/20080916/796e90f6/attachment.htm" target="_blank">http://openid.net/pipermail/general/attachments/20080916/796e90f6/attachment.htm</a><br>
<br>------------------------------<br><br>_______________________________________________<br>general mailing list<br><a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br><a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br><br>End of general Digest, Vol 25, Issue 27<br>***************************************<br></blockquote></div><br>