[java-identity-provider COMMIT] in /trunk/idp-saml-impl/src: main/java/net/shibboleth/idp/saml/impl/profile/saml1/Sig...

[Brent Putman]

On 2/6/14 7:53 PM, Cantor, Scott wrote:
> Encryption also gets a bit complex (three different types of objects),

Yes, although my existing model might work for at least 2 of those.  The
params for attributes could live under the attribute resolution context
(presumably they are encrypted before leaving that "subsystem") and the
params for assertion could live, as you said, directly under the PRC or
wherever general profile response intermediate data lives.  Params for
NameID, I'm not sure, maybe there is a different and natural
place/subsystem for that, but I'm not familiar with all of that in the
IdP at the moment.


> plus we had the conditional notion, where it depended on the transport.

Yeah, we still need to figure that out - either how to do it, or I think
you mentioned maybe considering not supporting in v3, esp since what we
did is iffy anyway.


> Ideally I guess I'd like to bury that as much as we can into "setup"
> stages so the actions just look for the parameters or do nothing,

Me also.

>  but I
> suspect we'll want to think about different contexts, or maybe
> more-descriptively named slots on the one context.

Certainly can, if it makes sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140206/1b453391/attachment.html