<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 7/26/16 5:18 PM, Cantor, Scott

      wrote:</div>

    <blockquote

cite="mid:9846A6064BD102419D06814DD0D78DE11299C537@CIO-TNC-D2MBX02.osuad.osu.edu"

      type="cite">

      <blockquote type="cite">

        <pre wrap="">a Jira issue.

</pre>

      </blockquote>

      <pre wrap="">

Functionally speaking, yes, either we have to do that, or we need more flexibility in whether that check gets done by the decoder of the NameID.

Policy-wise, I don't know what is "right" because I haven't thought about the policy implications here. If the presenter here is the SP to whom the transient was issued, then I guess that doesn't seem inappropriate that the IdP would be willing to decode it. But that's off the top of my head.</pre>

      <br>

    </blockquote>

    <br>

    Hmmm, yeah. Good point about the policy implications.<br>

    <br>

    I was just trying to determine if the presenter to the Liberty SSOS

    flow is always the RP to whom the Assertion token's NameID was

    issued.  I *think* it is, because on each trip through the Liberty

    SSOS profile the new to-be-issued Assertion gets a new NameID

    generated from the resolved and c14n-ed principal name.  Initially I

    thought that the original SSO NameID was cloned each time and

    carried down through the whole delegation chain.  But I can't find

    any evidence of that, and it sort of doesn't make any sense.  I

    think the NameID generation part of the Liberty SSOS flow is just

    doing what the standard SAML SSO flow does.   So even for n-tier as

    opposed to the simple 1-tier, the assumption still holds.  I think.<br>

    <br>

  </body>

</html>