Shibboleth Developers

["RL 'Bob' Morgan" <>]

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

Just to clarify, non-browser cases do not "require that we support proof 
keys" any more than the web browser case does.  Some people feel strongly 
that the security benefits of tokens with proof keys should be available 
to apps that want to take advantage of them.  As far as I can tell the 
security interest isn't particularly dependent on the app protocol between 
Infocard client and RP.

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

Just to clarify, this means supporting self-issued cards as an 
authentication method to the IdP.  This is really just integrating an 
Infocard RP into the IdP.  The handling of key/PPID as user identifier is 
something any Infocard RP supporting self-issued cards has to do.  The 
additional consideration at the IdP is mapping this to existing user 
accounts, aka registration.

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

In my organization I see Infocard as an IdP authn method as likely being 
more useful in the near term than managed cards (issued by the IdP and 
consumed by app RPs), though obviously the latter is where the real 
promise of Infocard lies.

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

To the extent that there is anything in Infocard material saying who is 
supposed to trust whom (very little, to my knowledge), the common use case 
is the consumer case, where the IdP has essentially no organizational 
policy but is just serving the user's interests.  But I don't think this 
in any way is intended to tell organizational IdPs that somehow they are 
not permitted to have policy about what they send.  That would be absurd.

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

No more than the IdP would release every value if a SAML RP asked for an 
entitlement attribute.  Policy-based filtering is done by the IdP 
implementation in either case.

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

Microsoft has a document:

  Patterns for Supporting Information Cards at Web Sites: Personal Cards
    for Sign-up and Sign-In

available from MSDN, that covers some of this space.

 - RL "Bob"