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

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Abhi wrote:

<snip>

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

Yes, the method impl would cache claim 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.
> 
> 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.

Got it, thanks.