Shibboleth Developers

["Scott Cantor" <>]

> 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?

Shibboleth identifiers are as SP-specific as you want them to be.

> Okay, so it comes down to this.  Transient identifiers cause problems
> when SAML tokens are converted into other tokens,

They cause problems when you want to share them between security domains in
ways that aren't appropriate. Within a domain, encryption can easily allow
them to be created or consumed in many different places.

> 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?

A persistent, opaque value is just as vulnerable to repeated queries as
anything else is. It's the persistence that allows this, not the privacy
properties. A transient identifier is effectively an opaque identifier with
one-time use properties.

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

Depends who you ask, I guess. The real issue is whether presence is
necessary to allow a query. Transients are really for enforcing presence for
queries. If you think about it, a non-query use case (say, pure push) has no
need to even stick an identifier in the assertion, since it never gets used
for anything. May as well fabricate something. Auditing can be done with the
assertion ID alone, for example.

> 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.

I'm not getting it. If it doesn't have a private key, then you can't *ever*
give it a certificate. 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.

> 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.

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?

But regardless, that wasn't my whole point. Just because it's bearer doesn't
mean it's short-lived. That's a requirement of SSO, not of bearer confirmed
assertions. 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.

-- Scott