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

[Michael McIntosh <mikemci@xxxxxxxxxx>]

I think my question is somewhat related to this thread...

I am implementing the Display Token for CardSpace interaction with the 
STS:

"Windows CardSpace is agnostic of specific token types that may be 
requested by a relying party and issued by an identity provider. The token 
returned by an IP/STS may be completely opaque to Windows CardSpace which 
simply provides a conduit. However, to allow informed user consent and 
release, the Information Card model introduces the notion of a display 
token. It is an informational token associated with the actual security 
token that essentially contains a friendly representation of the claims 
carried in the security token. Its friendly content can be displayed to 
the user in user interfaces."

The format is:

<wst:RequestSecurityTokenResponse>
  ...
  <ic:RequestedDisplayToken>
    <ic:DisplayToken xml:lang=?en-us?>
      <ic:DisplayClaim 
Uri=?http://.../ws/2005/05/identity/claims/givenname?>
        <ic:DisplayTag>Given Name</ic:DisplayTag>
        <ic:DisplayValue>John</ic:DisplayValue>
      </ic:DisplayClaim>
      <ic:DisplayClaim 
Uri=?http://.../ws/2005/05/identity/claims/surname?>
        <ic:DisplayTag>Last Name</ic:DisplayTag>
        <ic:DisplayValue>Doe</ic:DisplayValue>
      </ic:DisplayClaim>
    <ic:DisplayToken>
  </ic:RequestedDisplayToken>
</wst:RequestSecurityTokenResponse>

The current STS is given an RST with the Claim URIs and uses the 
IDigitalSubject to retrieve the associated attribute values:

attribute = digitalSubject.getAttribute(uriAttribute);

However, there is no current way for the STS to get the "friendly" 
DisplayTag value for the DisplayToken. Can we add the following to the 
IAttribute interface?

String getName();

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 11/29/2006 11:58:41 AM:

> 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
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev