<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2/6/14 7:53 PM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:CF199856.8703%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
Encryption also gets a bit complex (three different types of objects),</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:CF199856.8703%25cantor.2@osu.edu" type="cite">
<pre wrap="">
plus we had the conditional notion, where it depended on the transport.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:CF199856.8703%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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,</pre>
</blockquote>
<br>
Me also.<br>
<br>
<blockquote cite="mid:CF199856.8703%25cantor.2@osu.edu" type="cite">
<pre wrap=""> but I
suspect we'll want to think about different contexts, or maybe
more-descriptively named slots on the one context.</pre>
</blockquote>
<br>
Certainly can, if it makes sense.<br>
</body>
</html>