Shibboleth Developers

[Scott Cantor <>]

I think to boil my last response down a bit more, basically if you're using
SAML in some fashion for authentication, then you by definition do not have
trust in the credential that the user can supply directly to you.

An example is you don't have a password recorded for the user, or you don't
know how to accept X.509 certificates, or maybe you do, but don't share a
PKI environment that allows you to trust it, or in the simple case, the user
simply doesn't have one.

If you change that assumption and do have a user credential that you already
trust, then you're done. You now have a bound credential. If that credential
can then be leveraged into other information you need (i.e. attributes),
then that's great too, but now it's just a naming problem, for which we know
many approaches.

If you want to use SAML attribute authorities in that phase of the process,
nothing should prevent that, and obviously the Shib code and the means by
which we provide you the ability to trust and authenticate to SAML
authorities  and process the results should be useful. But there's no new
SAML to define there, I don't think.

All that said, if you don't get a credential you can trust, that doesn't
imply bearer tokens by definition if you were to use SAML. The browser
profiles do, as they exist today, but that's where we were exploring new
ground that would involve holder-of-key confirmation semantics. The rest of
the talk about DNs and so forth was just the federated naming question.

-- Scott