Org.eclipse.higgins.icard

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
This page describes the base ICard interface that all types of Higgins-compatible i-cards must implement, as well as several other optional interfaces implemented by specific I-Card Providers.

These interfaces are in a state of continuous evolution. We're trying to support real world demos (recently, for example on CardSpace-compatible interoperability) on the one hand, while also trying to build a robust abstraction layer around the i-card metaphor (e.g. as described here Wikipedia i-card), on the other. What's shown below on this page "works" (supports certain interop use cases), but some lower level implementation dependences are leaking up through the abstraction that will limit things we want to do in the future.

ICard Interface

//Returns the type of this i-card (e.g. "m-card", "p-card", "r-card", "z-card" etc.)
String getType();
// A card identifier that is unique to the card issuer. Or at least that
// is what we believe the semantics that Microsoft intended and we currently
// see no reason not to follow
// Return the identifier string
String getId();
// The unique identifier of the i-card in the i-card registry.
// Because different i-card providers could contains i-cards with the same
// ID, it could be difficult to retrieve the same i-card from the i-card
// registry again using i-card ID.
// The UUID must be unique over all i-card providers in the i-card registry
// to allow retrieve the same i-card from the i-card registry multiple times.
CUID getCUID();
// The version of the card. Useful in subsequent import operations,
// so that cards can be updated or overwritten.
String getVersion();
//the human friendly name of the card. The only thing that will be
// possible to modify after the import.
String getName();
// Representation of a background image of the card.
byte[] getImage();
// The mime type of the background image (JPEG or GIF).
String getImageType();
// Name of the issuer of the card. Used to match the required issuer, if a relying party specifies an issuer in the policy.
String getIssuer();
// The human friendly name of the card issuer
String getIssuerName();
// Returns when the card was first issued, created, originated
Date getTimeIssued();
// Returns (optionally) the time after which the card should
// be considered expired, invalid. Otherwise returns null
Date getTimeExpires();
// If card handles only simple claim types then
// return a list of all possible types of claims that are supported
// throw exception otherwise
// This is here for backward compatibility with CardSpace cards
//
// Note: this is a convenience method that does the equivalent of
// c = getContext(); and then (presuming c has a simple schema)
// does creates a linear list of claim/attribute types from
// the schema of c (retrieved by c.getSchema())
List getSupportedSimpleClaimTypes() throws ComplexSchemaException;
// List of all possible types of claims (as String) that are supported.
public List getSupportedClaimTypesUris();
// List of claims provided by this ICard.
Iterator getClaims();
// Retrieve the value of a simple claim type
IClaim getClaim(String type);
IClaim getClaimByShortName(String shortTypeName);
// Provider of this card
ICardProvider getProvider();
//
String getDescription();
//
void setName(String newName) throws CardException;
//
void setImage(byte[] newImage, String newImageType) throws CardException;
//
void setIssuerName(String name) throws CardException;
//
void setExpiredTime(Date date) throws CardException;
// The list of token types could be issued using this card (this method was moved from ITokenCard)
List getSupportedTokenTypes();
// Indicates that this card has been issued by user (claim values can be editable)
public boolean isSelfIssued();
// Date when the card was last updated
Date getTimeLastUpdated() throws CardException;

To Do

Future: we may want to add methods to the a human friendly text name and an icon that informs the user about the kind of data access "protocol" used (if any) to retrieve the underlying data. Examples of strings might be "LDIF", "OpenID", "WS-Trust", etc.

Future: we may want to add methods (analogous to the ones mentioned above) to inform the user about the format of the underlying data (e.g. LDAP, RDF, RDBMS, email contacts, etc.)

IInformationCard Interface (extends ICard interface)

All CardSpace-interoperable cards must implement this interface.

// Random entropy used for computing the PPID claim value for the card
byte[] getHashSalt();
// Used as the entropy to generate the token signing key
byte[] getMasterKey();
// XML representation of the card in RoamingInformationCard format. This Element should be created within the passed Document
Element toXML(Document doc) throws CardException;