Parsing the trust engines

[Brent Putman]

On 4/25/14 7:01 AM, Rod Widdowson wrote:
> Indeed the *only* trust engine that I can see us having any need to
> configure via relying-parety.xml is the one which is to be injected into the
> metadata certificate filter.

As we discussed today, that sounds fine.

> As such I am assuming that I can stub out those trust engines which were
> there really for supporting the old <SecurityPolicy/> parts of the config
> (which I believe we all agree will be represented differently and
> elsewhere):
>
> •	MetadataExplicitKey
> •	MetadataPKIXX509Credential
> •	MetadataExplicitKeySignature
> •	MetadataPKIXSignature

Yes.


> This "just" leaves the ones which might be useful in filtering metadata:
>
> •	Chaining
> •	SignatureChaining
> •	StaticExplicitKey
> •	StaticPKIXX509Credential
> •	StaticExplicitKeySignature
> •	StaticPKIXSignature


Yes.  Since it's related, I just wanted to bring up the historical use
of the Static- types of things there.  Everything we've supported
vis-a-vis metadata signature validation in the past was amenable to just
using a static credential/PKIX resolver that was implicitly the one
relevant to the metadata being defined.  So we didn't bother to go
farther with that.

In v3, we'll have the capability for the dynamic metadata resolver,
where that assumption breaks down.  So for that case, you couldn't use a
Static- credential/PKIX resolver, but rather one which actually honors
the CriteriaSet passed to the resolver and filters what it returns
accordingly.  For Credentials, we do have the
CollectionCredentialResolver which would work for that case (e.g. the
metadata signature filter might construct and pass an EntityIDCriterion,
and you only get Credentials back which are labeled with that entityID).

Just wanted to note this for the record, and also state my current
understanding that: 1) we don't want to define *new* custom schema
things, and therefore we would not define any new config schema for
something like a "CollectionExplicitKeySignature" TrustEngine, and 2)
that that case would instead be handled by defining such a TrustEngine
elsewhere via Spring beans and injecting that bean ref to the metadata
signature filter, i.e. the advanced config cases that we've previously
mentioned.  Anything wrong with that?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140425/d2a76961/attachment.html