Shibboleth Developers

> These are my recollections of suggestions for improvement
> of our infocard support from Monday's call.

thanks very much!

here's some additional notes from the conversation, providing a bit 
of background on the questions.

Some additional notes:

1) There was some discussion about the need to support more than a 
web-based use case; it was noted that Bandit has begun to think about 
this use case. Supporting this use case would require that we support 
proof keys (non bearer tokens). We agreed to think about including 
proof keys (symmetric binding, fiull WS-Trust implementation) in 
Version 2 of the Shib CardSpace support.

2) re extending the IdP to support self-issued cards... Jim noted 
that Shib would have to associate the keyinfo of the private card 
with a user of the IdP. We agreed that it would be sufficient for us 
to provide a working example (based on a package such as derby?); 
deployers would have lots of options to choose from.

Jim also noted that the registration page required by this step would 
be the first actual web page that a standard IdP would present to the 
user.

(this may be wrong) In order to get a self-issued card from a browser 
user, we'd probably need a full WS-Trust implementation, and might 
need a pseudo java SP implementation. The CS spec's recommend using 
symmetric binding; could be implemented with just TLS.

We decided we'd like this in version 1, but its not required.

3) Attributes -- quite a bit of conversation....

we noted some major differences between the Shib model and CS model:

-- the CS model expects a user to have a few cards, from different 
issuers. We're thinking about a model where a user would have a few 
cards from the same issuer (the different cards would release 
different attributes).

-- in a standard Shib model, ARPs within the IdP control attribute 
release; they are typically managed by a site. In the CS model, the 
user trusts the RP, so the IdP is also supposed to trust the RP, and 
do what the user instructs it to do.

-- Shib ARPs were designed to allow the filtering of multi-valued 
attributes. CS doesn't provide any such filtering. A card might say 
"release entitlement" -- does that mean we release every value?

There was a strong feeling that the ARP engine should somehow be 
involved in the attribute release process.

We decided to provide a site with a set of templates to support the 
set of cards they decide to issue.

Q -- will Spring allow the use of two different ARP engine + 
config's? One for standard Shib, and one for CS (eg have different 
default release policies for these two situations?)

Q -- does the ARP engine know the protocol that's being used (eg if 
SAML, release nothing; if CS, allow user to control)

4) RP Identity -- Because CS does not have a concept like entitIDs, 
our sense was that we need to extend the metadata interface, to allow 
looking up by endpoint (which is what CS does provide)

5) Card Image -- Jim has been putting a watermark on the card's he 
issues -- the user's name.

6) For SP support of self-issued cards, we decided to punt the 
problem tot he application. The SP would pass along all the info it 
receives, and let the application decide what it wanted to do with 
this info.