Shibboleth Developers

[Nate Klingenstein <>]

Josh,

Thanks for pointing this out to me.  I've always been quite accustomed  
to the idea of persisting the session while a back-channel query was  
made: that's how the classical Shibboleth flows have always worked,  
after all.

However, I'm not sure how bearer artifact works at all without doing  
this.  After all, don't the user and the session have to be tied to  
the subsequent artifact query more strongly in the case of bearer  
delivery of artifacts?  Section 3.6.3 of SAML2Bind mentions this fact,  
so I think it'd be redundant here.

Actually, the use of holder-of-key assertions would probably allow a  
client to "claim" an artifact without persisting state, which is  
possibly useful in load-balanced environments.  I might say something  
about that instead. :D

Interesting ideas,
Nate.

On 12 Mar 2008, at 12:38, Josh Howlett wrote:

> When I first read this, I immediately wondered how the user agent
> demonstrates to the SP that it possesses the private key associated  
> with
> the keying information included in the assertion's
> <saml:SubjectConfirmation> given that the artifact resolution is a
> direct callback to the IdP.
>
> It took me a minute to realise that the SP, of course, can  
> authenticate
> the connection used to deliver the artifact (via the user agent) and
> persist the relevant TLS state until it resolves the assertion at  
> which
> point it's done.