Shibboleth Developers

[Tom Scavo <>]

On 12/11/05, Scott Cantor 
<>
 wrote:
>
> ... the notion of NameID TTL doesn't exist in SAML.
> It also makes little sense except in one specific case, transient IDs.

Yes, which argues for a persistent identifier such as X509SubjectName,
but there goes anonymity right out the window.  I guess what I'm
looking for is an opaque, persistent identifier.  There is no such
beast in SAML 1.1 unless we get creative and "opacify" X509SubjectName
or emailAddress.  I'm not sure what this gains us, however, since
Shibboleth name identifiers are not SP-specific.  Maybe they should
be?

Okay, so it comes down to this.  Transient identifiers cause problems
when SAML tokens are converted into other tokens, while persistent
identifiers permit SPs to phish for attributes.  One way out of this
dilemma, I guess, is to fabricate an opaque identifier with a one-time
use semantic.  Has this been considered or am I way off base?

Maybe this is overkill.  Who cares if the SP queries for the same
attributes over and over?

> I don't see why the bearer credential needs to be
> short lived, since this isn't a standard profile. For that matter, why is it
> even a bearer credential? If you're going to turn around and issue
> certificates, why not just have some mechanism to embed the public key in
> the assertion up front, and then you combine that with TLS or something when
> you deliver the assertion as input to the CA.

No, sorry, I failed to clarify the use case.  It is unspecified how
this non-browser client (passively) authenticates to the IdP, in the
same way it is unspecified how a browser user authenticates as a
prelude to the browser profile.  The non-browser client may or may not
have a certificate.  Most likely it does not, which is why 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.

Tom