Shibboleth Developers

["Scott Cantor" <>]

> > No, that part is meaningless but transparent to SAML. I mean the X.509
> > authentication part.
> 
> That's not part of the Attribute Sharing Profile, so I still don't
> understand your concern.

Last time I read it, the X.509 profile had steps in it related to browser
authentication using a certificate. I felt that was unnecessary because it
had nothing to do with the SAML profile, which amounted to "standard query
plus specific security options".

> Agreed, but one concludes from this that multiple
> <md:AttributeService> elements within a single
> <md:AttributeAuthorityDescriptor> element won't work in general, which
> might be a problem (see below).

They work fine, *generally*. If specific profiles overlap, then one or more
of them are broken from a metadata point of view or were not intended to
co-exist. Shibboleth queries, for example, are probably broken from a
metadata POV. It's a profile of SAML queries (the Resource thing) but we
used the 1.x SOAP binding string by itself.

From a 2.0 POV, I don't think there's any intent to support any new SAML 1.x
functionality. So there's no overlap from that end of things, and 2.0 won't
collide with 1.x.

> What I think you're suggesting is that these various AA endpoints can
> not coexist in a single metadata file.

Not true, necessarily.

> So if, for example, a group of
> TeraGrid service providers joined InCommon, a new process for
> producing and distributing TG-specific IdP metadata would have to be
> devised.  Does that sound right?

I would have to see evidence of that, along with any evidence InCommon plans
to go beyond supporting Web SSO any time soon.

If GridShib is working today, then it must be reusing Shib-profiled 1.x
queries, so I don't see why there's a problem or a need for anything new
there. If it wants to use 2.0 queries, I think it ought to use standard 2.0
queries for that, and that doesn't collide, so no problem.

But I caution you that you can't use metadata as a substitute for a general
security policy language. It will never reflect all the signing, encryption,
algorithm, authentication, etc. options that exist in the world and it was
never meant to. And even if it did, real-world interop ends at ds:KeyInfo
anyway, so it's just illusion.

-- Scott