<div dir="ltr">I just love a good topic to get the creative juices flowing from so many brainy people. &nbsp;Thanks all for your ideas. &nbsp;<div><br></div><div>Regarding George&#39;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? &nbsp;Regarding this loose trust relationship between the OP and Org XYZ, what would that constitute? &nbsp;</div>
<div><br></div><div>The few RPs that would be interested in my membership can have specially crafted AX fetch requests, no problem. &nbsp;But these RPs need to be able to work against whatever OP the authenticating user happens to choose. &nbsp;If only a few OPs might support these signed AX attributes that&#39;s fine, as long as the user has a choice and there is no strong affiliation between OP, RP and Org. &nbsp;</div>
<div><br></div><div>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. &nbsp;Then any AX-fetch (with my permission) would retrieve that and the RP could check the signature. &nbsp;The only thing remaining in my mind is how the RP could verify the signature. &nbsp;Can an ordinary public HTTPS server cert on <span class="Apple-style-span" style="font-style: italic;">Org</span>.com be used to verify a signature if it is signed the right way? &nbsp;Or is there some other way to do that?<br>
<br><div class="gmail_quote">On Tue, Sep 16, 2008 at 6:26 AM, George Fletcher <span dir="ltr">&lt;<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Per Dick&#39;s response earlier in the thread, I don&#39;t see why using an OP of my choice with a third party asserted attribute of my membership in org XYZ isn&#39;t sufficient to meet this use case.<br>
<br>
Basically, I&#39;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.<br>

<br>
This should be completely doable with the existing OpenID 2.0 and Attribute Exchange specs. Is the issue what Peter mentioned that there aren&#39;t many AX supporters right now?<br>
<br>
Of course, there will have to be a &quot;trust relationship&quot; between org XYZ and my preferred OP, but I don&#39;t see that trust as any deeper than the &quot;trust relationship&quot; between and RP and an OP.<br>
<br>
Thanks,<br>
George<br>
<br>
Andrew Arnott wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="Ih2E3d">
You&#39;re affirmative action example is well taken. &nbsp;Obviously if an OP is the best solution we should go with it. &nbsp;But just imagine what all these spoons of sugar are going to do to me...<br>
<br>
Suppose I&#39;m a member of 15 organizations (that&#39;s conservative) between my professional, social, personal lives. &nbsp;Some RP could be interested in providing specialized services if I am a member of Org XYZ. &nbsp;Another RP may offer 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 identity XRDS file now has at least 15 providers listed. &nbsp;Powerful, perhaps. &nbsp;Dangerous: yes!!! &nbsp;If OpenID&#39;s weakness already was that if an OP was compromised then all Identifiers that allow that OP&#39;s assertions are now compromised, then that weakness is proportional to the number of OPs that are listed in my XRDS file. &nbsp;I for one do NOT want 15 Providers listed in my XRDS file. &nbsp;There was a time I thought more was better, and to date I have some 5-6 OPs listed, but I&#39;ve considered narrowing that down to just 2-3 to decrease my risk surface area.<br>

<br>
Using OAuth as a post-authentication step of confirming membership is an interesting idea and should work. &nbsp;In the end, whether we use OpenID or OAuth, it seems we&#39;re mixing authentication and membership, or authorization and membership, in order to just get membership. &nbsp;Too bad there&#39;s not just a way to get &quot;membership&quot;.<br>

<br>
Yes, InfoCard managed cards solve this problem, although not as implicitly as I&#39;d like. &nbsp;I&#39;m hoping OpenID can have a solution of its own.<br>
<br></div><div class="Ih2E3d">
On Mon, Sep 15, 2008 at 5:12 PM, Eran Hammer-Lahav &lt;<a href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a> &lt;mailto:<a href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a>&gt;&gt; wrote:<br>

<br>
 &nbsp; &nbsp;This is like applying affirmative action to cooking. &quot;This cake<br>
 &nbsp; &nbsp;calls for two spoons of sugar but we don&#39;t have enough people<br>
 &nbsp; &nbsp;using lard in cakes, so I am going to use it instead...&quot;<br>
<br>
 &nbsp; &nbsp;Looks like they want to use OpenID as an assertion verification<br>
 &nbsp; &nbsp;protocol, allowing them to confirm that a given user is in fact a<br>
 &nbsp; &nbsp;member of their organization. If all they want to do is assert the<br>
 &nbsp; &nbsp;claim, they can use both OAuth and OpenID, each with a different<br>
 &nbsp; &nbsp;set of extra features. If they use OpenID, a side-effect of this<br>
 &nbsp; &nbsp;will turn them into an Identity Provider, but if this is not their<br>
 &nbsp; &nbsp;intention, they should not use that identifier internally, but<br>
 &nbsp; &nbsp;instead accept OpenID.<br>
<br>
 &nbsp; &nbsp;In other words, they should be an OP for assertion verification,<br>
 &nbsp; &nbsp;and RP for site login.<br>
<br>
 &nbsp; &nbsp;EHL<br>
<br>
<br>
<br>
 &nbsp; &nbsp;On 9/15/08 4:45 PM, &quot;Andrew Arnott&quot; &lt;<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a><br></div><div class="Ih2E3d">
 &nbsp; &nbsp;&lt;<a href="http://andrewarnott" target="_blank">http://andrewarnott</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt;&gt; wrote:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;I just spoke with an organization that wants to become a<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Provider so that other RP web sites can specifically tell if<br>
 &nbsp; &nbsp; &nbsp; &nbsp;the logging in user is a member of this organization by<br>
 &nbsp; &nbsp; &nbsp; &nbsp;whether their OpenID Identifier was asserted by that org&#39;s OP. &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Ideally, I&#39;d like this org to choose to be an RP instead of an<br>
 &nbsp; &nbsp; &nbsp; &nbsp;OP because there are already too many OPs out there and not<br>
 &nbsp; &nbsp; &nbsp; &nbsp;enough RPs, IMO. &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp;How can an RP accept an OpenID Identifier from arbitrary OPs,<br>
 &nbsp; &nbsp; &nbsp; &nbsp;but at each login determine whether the Identifier represents<br>
 &nbsp; &nbsp; &nbsp; &nbsp;a user who belongs to a particular Organization? &nbsp;Basically<br>
 &nbsp; &nbsp; &nbsp; &nbsp;the Organization needs to send an assertion about the<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Identifier&#39;s membership, but only be willing to do so if that<br>
 &nbsp; &nbsp; &nbsp; &nbsp;identifier is confirmed as having logged in successfully to<br>
 &nbsp; &nbsp; &nbsp; &nbsp;that RP. &nbsp;This would be easy to do if that Org was an OP, but<br>
 &nbsp; &nbsp; &nbsp; &nbsp;I&#39;m trying to reduce the # of reasons to be an OP.<br>
<br>
<br></div><div class="Ih2E3d">
------------------------------------------------------------------------<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>
 &nbsp;<br>
</div></blockquote>
<br>
</blockquote></div><br></div></div>