PolicyFactory: This class has one method which instantiates a class that exposes the Policy interface below for the given policy type.
Policy ParsePolicy(String policy, String type) throws PolicyParseException, UnsupportedPolicyTypeException
The factory implementation is quite simple, but it allows for extensibility---various different policies can be registered and instantiated dynamically, etc.
// contains the parser for the policy string new(String policy) throws PolicyParseException // matches the policy and returns a list of lists indicating the user choices // can return an empty Choices structure if no choices are needed Choices match(Icard Registry) throws UnsatisfiablePolicyException // makes a token which satisfies this policy using the Selection of credentials DigitalIdentity getDigitalIdentity(Selection) throws InvalidSelectionException
The Cardspace Policy Class
The cardspace policy class implementation of _new_ would parse the policy. The _match_ method would subsume the role of the ISS as it is currently described. In particular, it would iterate through the list of cards retrieved from the registry, call isMatch on each one, and return a list of those which matched.
The getDigitalIdentity would simply call the similar function of the underlying I-card.
Idemix Policy Class
An Idemix policy class implementation would have the flexibility to do more complicated matching, and more complicated processing to get the token.
Given these two classes, the RP protocol support class would then handle the details of marshalling/unmarshalling, formatting parameters and inputs, and making the right calls to the PolicyFactory and resulting Policy class.
This architecture allows for many more interop possibilities. Anyone who can implement a policy language for _requesting_ such credentials can plug into this.