Attribute Aggregation

Attribute Aggregation

Convener: David Chadwick

Notes-taker: David Chadwick Tags:

• Grouping attribute claims together
• Authenticating the user
• Service Provider Policy

Discussion notes:

It was agreed that multiple attributes from multiple IDPs are needed in a single session.

Most IDPs (probably all) are also SPs, and most only issue a single attribute to users. (Passports and driving licenses are the exception rather than the norm).

This means that with Information Cards the user needs to be able to select multiple cards in one go.

Paul showed a video from a French consortium, FC2, that have built a demonstration version of a multi-card Information Card selector.

The Card Selector must be capable of authenticating the user to the highest LOA level possible (4) but should only authenticate the user to the lowest level that is sufficient for the current SP.

The authentication needs to go from the user to the selector, and from the selector to all the IDPs whose attribute claims are needed.

The two signature technology from Identica could be helpful.

Many organisation use the back channel today, and this model may still be helpful for picking up extra attributes. The card selector could be an enabler for setting up back channels. This could be coupled with the Kantara UMA work so that the user’s policy on card selection is always followed.

The SP’s policy needs to say which attributes are wanted and which issuers are trusted to issue them. The policy also needs to say what Level of Assurance (LoA) is needed for each attribute.

The card selector should pre-select the cards that are most appropriate for the SPs policy.

It would help the user experience if the card selector could automatically evaluate the SP’s policy and carry it out automatically with little or no user involvement. Only involve the user in exceptional situations. The card selector could have defaults built in so that it automatically knows which set of cards to send to a particular SPs.

One problem that was identified is that users may go for one supercard that gives them most accessess to most SPs with with least hassle. Maximum privileges rather than least.

But this can be countered by having a single attribute card that can be asserted at the 4 different LOA levels depending on the strength of the user authentication in the current session.