On 2010-06-08, at 1:36 PM, SitG Admin wrote: > 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.
I think the use case from Patricia is different. To access a particular resource, the user might need to be over 21 and a BC resident -- assuming that two different authorities are required to make these claims -- this requires claims from more than one IdP / OP. -- Dick _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
