SignAssertions action not needed ?

[Cantor, Scott]

On 2/5/14, 9:58 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 2/5/14, 9:38 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>>
>>Related: I saw what you did today with the Decrypter and new constructor
>>taking DecryptionConfiguration.  That definitely wasn't what I had been
>>thinking - but I'm not sure it's wrong, it depends.  I had not been
>>planning that the security -Configuration classes
>> would be inputs into anything other than the corresponding -Resolver
>>which produces the associated -Parameters (i.e. like my above example for
>>signing).  All other runtime components would consume only the
>>-Parameters instances.

Correct me...

I think what you're saying is that the idea was that the
SecurityConfiguration.get*Configuration() interfaces are supposed to be
the static settings applied via the RelyingParty configuration (syntax
TBD).

Then some kind of Resolver thing takes that interface + metadata + ? and
produces a -Parameters object that contains the effective settings, and
that's what should be used to drive
signing/encryption/validation/decryption.

If so, my concern is partly in not having to derive those mid-stream
inside the profile actions (we should do it once, and then hang that off
the context somewhere), and partly that the code looks kind of backwards
to me. I would think you'd want the final Parameters exposed via
interface, because then the resolver can produce an
implementation-specific object to expose them to the runtime.

Whereas a lot of the current ProfileConfiguration classes are pretty much
just simple structure classes with get/set methods, which matches the
current -Parameters classes.

So it's sort of backwards in my mind, which is why I probably had them
reversed conceptually.

-- Scott