<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Hi Matt and Brian – let’s discuss at the meeting tomorrow. Current thinking is that the IdP is primarily responsible for communicating completion to users who would be signing into the app. Hence, if the IdP experienced a transient failure,
expectation is that it wouldn’t message the users. It may retry until completion is successful.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Based on implementor feedback, I updated Section 6.2.3.2 to clarify the idempotence requirements.<o:p></o:p></p>
<p class="MsoNormal"><a href="https://bitbucket.org/openid/fastfed/src/master/text_spec/FastFed-1.0-Draft-01.txt">https://bitbucket.org/openid/fastfed/src/master/text_spec/FastFed-1.0-Draft-01.txt</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Darin McAdams<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Openid-specs-fastfed <openid-specs-fastfed-bounces@lists.openid.net> on behalf of Openid-specs-fastfed <openid-specs-fastfed@lists.openid.net><br>
<b>Reply-To: </b>Matt Domsch <matt.domsch@sailpoint.com><br>
<b>Date: </b>Monday, August 19, 2019 at 1:37 PM<br>
<b>To: </b>Openid-specs-fastfed <openid-specs-fastfed@lists.openid.net><br>
<b>Subject: </b>[Openid-specs-fastfed] FastFed Process Clarification<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Forwarding on behalf of my colleague Brian Rose, who is developing an internal demo of FastFed, initially with SailPoint as the application.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Matt Domsch</span></b><span style="font-family:"Arial",sans-serif"><br>
</span><i><span style="font-size:9.0pt;font-family:"Arial",sans-serif">VP, Lead Corporate Architect</span></i><span style="font-size:9.0pt;font-family:"Arial",sans-serif"><br>
<span style="color:#00B5E2"><a href="mailto:matt.domsch@sailpoint.com"><span style="color:#00B5E2">matt.domsch@sailpoint.com</span></a></span></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">mobile: 512-981-6486</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#00B5E2">
</span><span style="font-family:"Arial",sans-serif"><br>
</span><b><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#00B5E2"><a href="http://www.sailpoint.com/"><span style="color:#00B5E2">www.sailpoint.com</span></a></span></b><o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Brian Rose <brian.rose@sailpoint.com> <br>
<b>Subject:</b> FastFed Process Clarification<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Hey all,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I have been implementing a demo for the FastFed process for SailPoint. I have been using the “FastFed Scenario #1A with SAML + SCIM” document as a basic guideline for the process, which is a great outline for understanding the steps.
I am mostly complete but have run across a something that could use some clarification.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In “Step 9”, the IdP makes a POST to the SP’s “<span style="font-size:9.0pt;font-family:"Courier New"">fastfed_handshake_finish_uri</span>” endpoint. This seemingly indicates that the handshake is complete, but at this point, the SP returns
information of its own. The IdP then uses that information to query the SP’s SAML metadata and add/import it as a relying party trust. As far as the SP is concerned, the process is over and has been successfully completed. Unfortunately, the SP has no way
of knowing whether the IDP succeeded in setting up the trust. In the event that the IdP is unable to finish the process (SAML endpoint error, unable to import, etc.), SSO will not be set up properly but the SP will now have SSO configured with an unusable
IdP. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Is this the correct behavior? <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I know that the IdP returns an informational page, which could include a success or an error, but that still doesn’t provide the SP with any indication of success, especially if the process is kicked off in another tab/popup, as was demoed
in the Identiverse video by Darran McAdams and Erik Gustavson. It seems like there should be a final callback to the SP from the IdP to an actual “handshake finish” endpoint with metadata indicating the results of the final step from the IdP. This would
give the SP the ability to set up polling for completion/error when the process starts and then poll on that flag until it receives a true finish from the IdP, allowing scenarios like a UI refresh or kicking-off dependent backend workflows (logging, auditing,
notifications, etc.).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Brian Rose<o:p></o:p></p>
<p class="MsoNormal">SailPoint<o:p></o:p></p>
</div>
</body>
</html>