Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Questions about I-Card Interface


Abhi wrote:
> 
> Hi Folks,
> 
> I have been working on the RP Prot Support and ISS interfaces, and have
> two question about some of the decisions we made at the Boston F2F.
> 
> (1) The I-Card also has a getSupportedSimpleClaimTypes() method, but it
> does not have a getClaimValues() method.  In fact, we discussed at
> length how the I-Card is just a pointer to the claim values.  However,
> when we display the Icard to the user, and then the user clicks "show me
> what i would send under this card," these values must be extracted to
> display an I-card to the user.
> 
> By what method(s) should the caller retrieve these values?  Are they
> Idas methods?

The idea was that they not IdAS methods. (In the Higgins is layered, I-Card
Provider implementations do not necessarily use IdAS at all (though many
will)). 

The real answer is that this is a design flaw. The methods that you need are
missing from the base ICard interface here
(http://wiki.eclipse.org/index.php/I-Card_Interfaces#Base_ICard_Interface).
For "simple" claim types, I've just added this:

// Retrieve the value of a simple claim type
// Note: Implementations of this method will likely retrieve and cache all 
// supported simple claim type values in a single operation 
// Returns the value of the claim type ClaimType
String getClaimValue(String ClaimType);

The above proposed method is a stop-gap to let you proceed with your work
though it sidesteps the issue of how to get complex values. 

> 
> (2) The I-Card interface currently has an isMatch method.
> Philosophically, this means that the I-Card needs to be aware of Policy
> semantics.  Of course, there will have to be some component which knows
> about both I-Cards and Policies.  I would like to argue against this
> being the I-Card.  While there are many alternatives, does anyone have
> strong feelings about putting it into the I-Card?

I *think* I can guess why you think this matching logic shouldn't be
encapsulated within an I-Card (e.g. matching against policies that require
claims to be culled out of multiple cards), but could you please explain the
requirements as you see them. 


Back to the top