[OpenID] Too many providers... and here's one reason

[Shane B Weeden]

I think I'm repeating what others have said...

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.

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.

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.

Regards,
Shane.




"Andrew Arnott" <andrewarnott at gmail.com> 
Sent by: general-bounces at openid.net
16/09/2008 09:45 AM

To
"general at openid.net" <general at openid.net>
cc

Subject
[OpenID] Too many providers... and here's one reason






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
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080916/bcf8e66a/attachment-0002.htm>