Shibboleth Developers

[Jim Fox <>]

> > - If the Shib SP is modified to accept a "Shib InfoCard", will it
> > also be able to continue to accept the current flows? I.e. would it
> > be easy to support both?
>
> Cardspace defines two different general RP flows, one involving an STS at
> the RP site, the other is HTTP POST. I don't expect the POST option will be
> significantly different from what's there now, and it will probably look a
> lot like supporting SAML 1.0, 1.1, 2.0, and ADFS does.
>
> My feelings about APIs and invading applications are well known. If the app
> has to do anything to support this that's new, we've failed and the app will
> be broken.

The assertions delivered by Infocard carry the IdP's certificate --
used for the signature.  With that an SP should be able to find the
IdP in its metadata, federated or local, and thereby make use of some
of the normal shib tools: AAP, etc.  The assertions can be delivered
to applications through the standard shib environment variables.

> > And how does Federation metadata factor into all of this?
>
> Cardspace definitely requires its own security policy metadata and you have
> to post it where the client can get it. Not clear yet whether any kind of
> linkage to SAML metadata will be possible or useful. Much of its key
> management would fall into the category of what I would deem "insufficient",
> often times devolving to "hey, tell me your key and I'll use it", with the
> goal being minimal confidentiality, not what I feel is strong security.

An IdP can request (or require) that a SP include identity
information in a request.  That can be a location identifier or a
certificate (KeyInfo data).  As in the SP case, the IdP can use the
identity information to look up the SP in its metadata and apply
the normal shib rules: ARP, etc.  The IdP encrypts its reply with
the SP's certificate.

So I think we will be able to make some use of shibboleth's
trust infrastructure.

Jim