BC Government requirements for OpenID v.Next

[SitG Admin]

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