RE: [higgins-dev] Questions about I-Card Interface

[abhi shelat <abs@xxxxxxxxxxxxxx>]

Hi Paul, 

wow! you are quick.

See below.

> > (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. 

How would this be implemented?  Would the I-card now also cache its
ClaimValues?  Otherwise, if the card is "managed," would every
invocation of this function initiate a web-transaction with the remote
identity provider that retrieves the latest value to display to the
user?  If the remote idp requires authentication, you could imagine that
this spirals out of control---unless, of course, the i-card now also
contains a cached version of boths its claimtype and its claimvalue.


> > 
> > (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. 

yes indeed. the practical reason is that separating it this way also
makes it cleaner for handling idemix policies which are more complex
than just a list-of-claimtypes.

beyond that, conceptually, i think the role of an i-card should be crisp
and limited: it represents claimtypes and claimvalues. 

why should it know about the semantics of the claimtype (which is tied
to the policy language)? 

as a use-case, i envision using all types of identity cards in all types
of environments.  i can use my managed infocard in an idemix setting,
and perhaps i can use my openid card as part of a larger assertion
involving infocards and idemix.  to support this requires a more
complicated policy-matcher---but the point is that architecture
decisions should not limit the use of an identity.


~a