Follow-up on question that I recently asked on the users list about name ID support in Shibboleth IdP

[Cantor, Scott]

> -One whereby the IdP has to respond to an incoming name-id management
> request.

There are no meaningful use cases we know of for that unless you're linking IdPs together. The SP doesn't support initiation of this protocol because the primary use case for that in SAML was silly. An IdP acting as the SP in the profile would be a different story, but my SP doesn't ever act as an IdP.

> For the other case it is indeed more tricky. It really moves into the realm of
> user management. I could imagine that the IdP provides some API, which
> could be invoked by a custom user-management-GUI. E.g. the Web GUI is
> developed by the organization that uses Shibboleth and bundled into the
> idp-installer-web directory, just like a custom authentication plugin and login
> page. This GUI application can present the user some option to unlink the
> account or perform other updates that must be synchronized. The GUI
> application can then invoke the API on the IdP, so that the IdP can start the
> name identifier management protocol, or something like that.

Yes, which is a huge amount of work without a clear set of use cases, thus it isn't on the roadmap right now.

> On the other
> hand, I'm not sure from the Oasis spec if an ID-management request can
> actually go from IdP to IdP (potentially through a user-agent) or if it goes by
> definition from an SP to an IdP.

The profile is IdP and SP. Any IdP can be an SP, it's a question of functional roles, not absolutes.

-- Scott