<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 4/25/14 7:01 AM, Rod Widdowson
wrote:<br>
</div>
<blockquote
cite="mid:006f01cf6075$b9882060$2c986120$@steadingsoftware.com"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
As we discussed today, that sounds fine.<br>
<br>
<blockquote
cite="mid:006f01cf6075$b9882060$2c986120$@steadingsoftware.com"
type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<br>
Yes.<br>
<br>
<br>
<blockquote
cite="mid:006f01cf6075$b9882060$2c986120$@steadingsoftware.com"
type="cite">
<pre wrap="">
This "just" leaves the ones which might be useful in filtering metadata:
• Chaining
• SignatureChaining
• StaticExplicitKey
• StaticPKIXX509Credential
• StaticExplicitKeySignature
• StaticPKIXSignature
</pre>
</blockquote>
<br>
<br>
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.<br>
<br>
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).<br>
<br>
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?<br>
<br>
<br>
<br>
</body>
</html>