Shibboleth Developers

We spent the last 20 minutes of this week's call exploring one of the 
difficult questions related to a non-browser profile. We identified 
several different approaches that a client could use to "prove" that 
the assertions it supplies to a destination refer to the client (as 
opposed to being stolen, etc). Not surprisingly, the different 
approaches offer a range of "level of assurance" guaranties.

Our problem at this point is to determine which of these models we 
think is the most deployable, most supportable, and will  be the 
least pain for sites and users, while meeting the minimum required 
level  of security.

Here's a quick summary of each..... let the conversation being... I'm 
sure there are more pro's, con's, and issues.  Discussion on this 
email is encouraged.....

1) A bearer token model. This is clearly the simplest approach, and 
the easiest model to implement. Although there may be varying levels 
of comfort in acknowledging this fact, this is how basic non-SSL HTTP 
works. In this model, merely possessing the Assertions and being able 
to present them to a target is considered to be "proof" that they 
refer to the client.

Pro's: simplicity

Con's: uhhh... proof is mostly in the eye of the beholder, rather 
than in the protocol.

2) the approach described in my draft of monday (ie implementing a 
holder-of-key Confirmation Method)

http://stc.cis.brown.edu/~stc/Projects/Shibboleth/Version-2/Profile-Non-Browser/draft-carmody-non-browser-profile-01.html

see section 6.

Pro's: much much higher level of assurance, the "proof" can only be 
used by one target

Con's: much more complex to implement... on the order of SSL

3) the approach described in Von's Grid use cases (ie client 
authenticates to destination with a cert, destination uses that cert 
to obtain attributes from the origin site AA)

Questions: what kind of cert (ie how much identity?)

Pro's: also has a high level of assurance

Con's: uses client cert's......

4) suggested by Howard Gilbert from yale  -- leveraging SOAP 
forwarding capabilities (something I'm  not familiar with... from 
here on, its just raw notes from the call)  RL - this  model highly 
promoted by msoft;   this approach widely advanced in the biztalk 
world..... something about updating SOAP headers, and  passing the 
SOAP message along to the next entity in the chain.  Identity, cert 
of client never known to target. (rest of WS-trust -- lots of 
credential exchanges), which provides away to map the kerb cred to 
something else.

Pro's: ?? (Howard -- please help here!)

Con's: not implemented anywhere, as far as we know (of course, what 
do we know about this!)