<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 9/28/15 9:23 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:6B1339FB-7456-4424-8894-FB0CCADCB775@osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
These are the SPs the delegate is allowed to access? Constraints the delegation in other words.</pre>
</blockquote>
<br>
Yeah, I think so. That's looking at it in the opposite direction
from the way I phrased it, but I think they're the same. <br>
<br>
<blockquote cite="mid:6B1339FB-7456-4424-8894-FB0CCADCB775@osu.edu"
type="cite">
<pre wrap="">
Well, it's more abstract than that, it's just anything that relies on the IdP from my perspective.</pre>
</blockquote>
<br>
My go-to for these role definitions has always been SAML 2 core 3.4,
and this is what it says for RP:<br>
<br>
<tt>Relying Party</tt><tt><br>
</tt><tt><br>
The entity or entities expected to consume the assertion(s) to
accomplish a purpose defined by</tt><tt><br>
</tt><tt>the profile or context of use, generally to establish a
security context</tt><br>
<br>
So neither of the cases here fits that definition. Of course we can
(re)define things any way we like, but I generally start from things
that already exist. 'Cause you know, I'm lazy. :-)<br>
<br>
<br>
<blockquote cite="mid:6B1339FB-7456-4424-8894-FB0CCADCB775@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Maybe. But with the way that the looping over RPCs and predicates work, isn't it still going to be highly dependent on the order of RPCs? For any given state of the PRC, you're going to get one particular result, given a particular order of RPC's. Unless
you push stuff on and pull stuff off of the RPC like I was describing.
</pre>
</blockquote>
<pre wrap="">
Well, my incomplete thought was that it would obtain the relying party the predicates (which are mostly RP-based) are looking at using a lookup strategy, so the only ordering that would matter would be the same type of order that matters already.</pre>
</blockquote>
<br>
<br>
I don't really follow (yet), but I'll think about it more.<br>
<br>
<br>
<blockquote cite="mid:6B1339FB-7456-4424-8894-FB0CCADCB775@osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">The latter could still allow things to work the same way they do today (with a Criterion that holds the PRC), but also allows additional params to the call. I guess too late for that, until 4.x at least.
</pre>
</blockquote>
<pre wrap="">
Not necessarily, we could make it implement a dual interface and change the calling code we control to use the new one.</pre>
</blockquote>
<br>
A whole new interface, yes. Just remember that with generics you
can't implement an interface multiple times merely by varying the
generic params (due to the type erasure), so the new 2nd interface
couldn't be a Resolver.<br>
<br>
<br>
<blockquote cite="mid:6B1339FB-7456-4424-8894-FB0CCADCB775@osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>