Shibboleth Developers

[Tom Scavo <>]

On 12/11/05, Scott Cantor 
<>
 wrote:
>
> Shibboleth identifiers are as SP-specific as you want them to be.

Could you explain a bit more what you mean?  (The target SP is not
involved in the production or consumption of the identifier AFAIK.)

> > The non-browser client may or may not
> > have a certificate.
>
> I'm not getting it. If it doesn't have a private key, then you can't *ever*
> give it a certificate.

Referring to the original post of this thread, the client does not
have a credential initially (exchange 1).  The CA specified in
exchange 2 is an online CA, that is, it will gladly convert a
username/password (say) into a short-lived X.509 credential, which it
returns to the client via some unspecified protocol.  So, in
principle, we want to put an SP in front to control access to the CA
via SAML.

> If it does have a private key, why not use it? Not
> for authentication, but as an input to the IdP. All you're requiring then is
> a TLS connection during the authentication, for example.

This is how the client authenticates to the Grid SP during exchange 3.

> > ... the CA at
> > step 2 is prepared to issue a short-lived EEC in return for a SAML
> > assertion.  Seems like a bearer assertion to me.
>
> Not to me. It can't issue an EEC without the client having a key and somehow
> proving possession of it first. The CA isn't generating the key for the
> client, right?

Sorry, I failed to make things clear before...the CA *is* generating
the key for the client.

> If you need to use bearer, just issue one that lasts as long as
> you want the EEC to last, and match that to the TTL of the identifier.

Okay.  So specifying Conditions to hold the TTL is the way to go in this case?

Thanks,
Tom