Condensed:
l) The protocol should facilitate multiple identity providers to be used to satisfy a relying party's requirements. Two common examples are i) when one identity provider handles the authentication event and another identity provider supplies identity attributes; and ii) when one identity provider handles the authentication event and some identity attributes, and another identity provider supplies additional identity attributes. In these cases, context and attributes need to be passed from one identity provider to another.
To suggest a different case, and a less common example: MultiAuth (see David Fuelling's work on this) can be used to store identity attributes *such that neither Provider knows the user's identity attributes*. In this case, only the Relying Party would be able to combine these pieces to see the user's protected data; the independent identity providers, it is assumed, would not cooperate with each other. (If this is a concern, more providers can be added, with the user's data protected if even a single party does not cooperate in the attack.)
The underlying math made simple: you (a user), wishing to secretly present the number 7 to your Relying Party, store "2" with one provider and "5" with another. The equation is "x+y=secret", but only your RP can calculate the secret; either provider, on its own, has no idea what the other number might be. Now, for the real world, use extremely high numbers (hundreds of digits) so they are harder to guess, and "XOR" (effectively allowing for subtraction without using negative signs) instead of straight addition. Two sets of meaningless data, neither intrinsically related to the secret data, but when combined they reproduce the original secret.
-Shade _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
