Shibboleth Developers

["Scott Cantor" <>]

> That's why the AuthorityBinding is so useful in a SecurityTokenReference.
> A consumer of such a SOAP header can be told where the IdP is, instead of
> having it in metadata.

I don't see any difference, and metadata is much more flexible.

> If AuthorityBinding is deprecated then perhaps the SAML Token profile

It's not deprecated, it's *gone*. There is no such element in SAML 2.0
because it serves no purpose.

> needs updated as it's very useful in this case of "metadata push" from IdP
> through SPa to SPb.

You don't have to push metadata through anything, there are many ways to
deal with obtaining it or abstracting it.

You also completely misunderstand the reason that element is sitting there
in the 1.0 profile. It's *not* to point at some *other* endpoint at the IdP,
like an AA. It's to explicitly tell you where to go to get that security
token. In the 1.1 profile, STRs can reference assertions by URL explicitly,
so the endpoint is right there in the URL. Nothing else to do. It is NOT
part of WSS to describe how a web service might go and get other tokens it
wants.

> Perhaps the SAML Token Profile could be updated to use elements from SAML2
> Metadata instead of the old SAML1.1 stuff.

See above, you don't seem to understand STRs. They don't reference "a place
you can get a token you might want", but rather a specific token that
already exists and is ready to be dereferenced. There is no reason I would
expect any metadata to show up in a WSS profile.

> If this sounds feasible we'd be willing to update the profile.

It makes no sense to me, but if you want to join the WSS TC, feel free. The
SAML token profile is pretty much done, so I don't think you're going to
have a lot of luck, but nothing's stopping you.

-- Scott