Shade,<br><br>The OpenID spec is written with one user controlling an identifier in mind. RPs all over the world are making that assumption. If an shared "group" identifier is ever used to log into any of these RPs, then people may be unwittingly sharing their data with a large group of people.<br>
<br>There are plenty of other more appropriate ways to assert groups. A simple AX attribute would suffice if the RP trusted the asserting OP. <br><br>Alternatively, and I like this idea the best, an OpenID discovery spec can be written around claims in general (since group membership is just a claim) such that an RP can verify that a claim can be asserted (perhaps along with an individual user identity) by using the same kind of post-assertion discovery step that RPs already use to verify the Claimed Identifier. <br>
<br>For instance, if group "student at ABC University" is interesting, let it be claim "<a href="http://abc.edu/student">http://abc.edu/student</a>". That's not an identity, it's a claim URL. Performing discovery on this URL yields an XRDS document specifying the OP(s) that are authorized to issue this claim. An RP interested in knowing whether a user is an ABC U student can send an AX fetch request with this claim. The OP determines whether that claim is appropriate for the active user however it deems fit, and sends back the OpenID id_res message including the claim if it is. The RP performs discovery on this claim URI and verifies that the asserting OP has authority to assert that and allows the student to access private resources.<br>
<br>If no individual identity is needed or relevant, then that identity-less scenario that I started on another thread would apply while still satisfying group membership checks.<br><br clear="all">--<br>Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">2009/5/12 SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Overloading our existing concept of an identifier to support identifying a group worries me. Most consumers expect an identifier to be for a person and are designed around this principle.<br>
</blockquote>
<br></div>
This worries me; I think it's narrow-minded to expect that users will always be identified individually. Interpreting the larger concept of "identity" as the smaller subset of "individuals" limits Consumer's ability to understand (and interact with) real-life relationships.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think if groups are useful their design should be different such that consumers are able to distinguish between a user and a group.<br>
</blockquote>
<br></div>
I'd like to see group identity right alongside individual identity, not relegated to an extension or otherwise consigned to optional implementation. If the RP doesn't need to distinguish between separate members of a group, it shouldn't have to work any harder technically to accept group logins.<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>
</blockquote></div><br>