Shibboleth Developers

["Scott Cantor" <>]

> As I understand what you are suggesting, an IdP id would be placed in
> the extension; that IdP would resolved by the service through the Shib
> Metadata API (which uses a proprietary metadata file distributed by
> some OOB method) to a set of one or more URLs to AAs associated with
> that IdP.

Well,

- we're moving to the use of standard SAML metadata and would encourage your
deployment to do the same

- you don't *have* to use the existing Shibboleth metadata subsystem to do
this work, we're just saying "use metadata to indirect the process", and if
you want to use our code or develop alternative plugins, you're welcome to

- the Shibboleth API knows nothing about files or anything else, it's an
abstract interface to the information, you can supply the data in whatever
format/mechanism you like

- the API is designed as a thin wrapper around the SAML metadata schema by
design, but it can certainly evolve or be subclassed to do other things or
support community extensions, which I'm in fact doing for Shibboleth so as
to avoid polluting the core API which will eventually be in OpenSAML

> As Tom mentioned the intent is to allow the service to authentication
> of the AA to the service.

I think this is sufficiently generic without saying "must use or have a
certificate" unless you want to constrain things to that degree. It's up to
you.

Shibboleth doesn't require use of PKI or SSL to do authentication of the
SOAP, we just happen to use that.

> Is the suggestion here that the identity of the AA is available
> through this interface?

The metadata API supports accessing information about the keys usable by a
given system entity. This could be implemented in many ways.

We then separate out the actual trust processing in the case where the
metadata doesn't supply an actual key. It might say "AA foo can use key bar"
and then the trust API answers the question "is this certificate usable" by
comparing it to that information, perhaps with path validation, etc.

-- Scott