Skip to Content.
Sympa Menu

shibboleth-dev - RE: Dynamic Federation

Subject: Shibboleth Developers

List archive

RE: Dynamic Federation


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: Dynamic Federation
  • Date: Sat, 1 Dec 2007 15:38:58 -0500
  • Organization: The Ohio State University

> Does Shib 2.0 provide similar metadata capabilities?

Yes, but we're still having discussions with them about whether we can agree
on common profiles for the use or exchange of metadata. We documented our
profile for metadata usage that doesn't involve extensions a long time ago
and it's been stable for years now, people just aren't using it broadly yet.
Now that there's more agreement (note I said more, not universal) that PKIX
is not an appropriate or usable technology to base SAML federation on,
there's an opportunity to get broader acceptance in other products.

But that doesn't mean things are going to change overnight, and it still
doesn't address metadata verification itself, which is not going to be a one
size fits all model. We want Ping to agree that runtime verification models
need to be separate from metadata verification and they seem to agree on
that. So that's an opportunity to shift the problem to a more easily
pluggable component.

2.0 supports several different models for metadata verification, including
pre-shared keys/certs and static trust roots anchoring self-signed metadata.
Plugging in more will be a simple matter. That's much easier than wholesale
replacement of trust engines that have to work correctly at runtime across
so many different situations (signing, TLS, etc.)

> I find their approach to discovery even more interesting. I don't
> think an SP can derive a user's IdP from their e-mail address in
> general. Suppose, however, the SP obtains a valid e-mail address from
> the user directly and then persists a mapping from this e-mail address
> to a persistent identifier (ePPN or ePTID) asserted by the IdP. Then
> the SP *can* determine the user's IdP from an input e-mail address.
> It's kinda like OpenID's approach to discovery, but using e-mail
> addresses instead of URLs (which may even be more palatable to users).

I think discovery by definition does not start after you collect all that
linking information. To be a solution that really advances things, it has to
address the initial cold call. Whether it works or not, Ping's proposal does
do that at the cost of constraining entityIDs and collecting PII. For some
situations, I'm sure that's workable. It should not impact our ability to
find agreement in other areas in any case.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page