<br><font size=2 face="sans-serif">I think I'm repeating what others have
said...</font>
<br>
<br><font size=2 face="sans-serif">In the Information Card paradigm this
sounds very much like the resource-STS scenario, as demonstrated by Microsoft's
AGE STS (https://relyingparty.federatedidentity.net/ageSTSRP/Login.aspx).
In that scenario the RP has policy that basically says "In order to
login to my RP, I need you to provide the 'age' attribute (which cards
themselves don't support as standard)". Metadata retrieved about the
issuerPolicy indicates you must obtain a token containing the age attribute
from the AGE STS, and to authenticate to that STS you use a self-issued
card which supports the date-of-birth attribute. The age STS then generates
a token containing the 'age' attribute using the date-of-birth attribute
it retrieved during authentication.</font>
<br>
<br><font size=2 face="sans-serif">In that way a proxy identity provider
entity (the resource-sts) uses one piece of data (date of birth) to generate
another piece of data (age) that is used by the target RP.</font>
<br>
<br><font size=2 face="sans-serif">It seems this is a similar use case
where you need a clearinghouse which identifies the organization(s) a user
belongs to and sets that in a custom SREG or AX attribute. This would in
essence be an OP, but that OP would require authentication via the user's
real OpenID from which it could determine how to populate the custom attribute.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Shane.</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Andrew Arnott"
<andrewarnott@gmail.com></b> </font>
<br><font size=1 face="sans-serif">Sent by: general-bounces@openid.net</font>
<p><font size=1 face="sans-serif">16/09/2008 09:45 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"general@openid.net" <general@openid.net></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[OpenID] Too many providers... and here's
one reason</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3>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. </font>
<br>
<br><font size=3>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. </font>
<br>
<br><font size=3>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.</font><tt><font size=2>_______________________________________________<br>
general mailing list<br>
general@openid.net<br>
http://openid.net/mailman/listinfo/general<br>
</font></tt>
<br>