<div dir="ltr"><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">Dear all,<br style="box-sizing:inherit">We (OKTA|Auth0) are taking a deeper look at FastFed Core and wanted to share some thoughts elicited by consulting the spec for prototyping.</div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><br></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><b>- 4.1.2.2 Endpoint discovery</b></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">At the present moment, the way the specification is structured seems to suggest that WebFinger is the primary mechanism implementers should consider for discovery purposes. However it seems that in concrete scenarios, SaaS type setups will likely to implement IDP or SP initiated discovery flows where the operator is asked to enter a URL, vs the relatively exotic WebFinger flow.<br style="box-sizing:inherit">If the spec would be more explicit about IDP&SP initiated discovery flows, perhaps mentioning them beforehand and giving them at least comparable space to WebFinger, the spec might prove to be more readily usable as implementation guide in a larger range of cases. At the moment the impression that WebFinger is the primary discovery method is hard to avoid.</div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><b> </b></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><b>- "destructive" handshake</b></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">The fact that a repeated handshake will result in overriding everything that changed since an earlier handshake can lead to unintended consequences, if multiple changes occurred. Not all the changes might be contextual to the reason for which a handshake was initiated, and applying them can effectively lead to destructive side effects. It would be ideal if handshakes could be more sophisticated- eg if I want to change attributes, it would be great if I could just signal that without renegotiating the entire range of settings currently under the purview of a full handshake.<br><b><br></b></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><b>Protocol-specific language in the spec</b></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">The current spec leans heavily on SAML for its samples- that might make it hard for readers who aren't conversant in SAML to understand core concepts, and in general might make it harder to discern what's SAML and that's FastFed specific.<br style="box-sizing:inherit">Using "pseudoprotocol" syntax, or presenting all samples in the spec in both SAML and OIDC syntax, might help to clarify intent and reach a wider range of readers.</div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><b><br></b></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><b>Catering to different reader roles</b></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">The spec does a good job of describing FastFed in its entirety, but it is somewhat hard to use if the reader is consulting it with the intent of implementing a real system. One reason is that SP and IDP parts are mashed together. It might be handy to separate them, or at least to decorate the relevant sections so that SP and IDP implementers have a very clear way of identifying the parts under their responsibility. Also: although the spec is named "core", it contains optional parts - although they are formally well defined, again for the sake of readability it would be useful to be explicit about what constitutes MVP and what's optional.</div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><br></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">Somewhat ill-timedly, I am heading out for two weeks of time off hence I won't be able to engage right away- but wanted to put the message out. I'll do my best to join one call once back in case you want to dig deeper in any of those items.</div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">Thank you, looking forward to contributing to the WG.</div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures"><br></div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">Cheers,</div><div class="gmail-p-rich_text_section" style="box-sizing:inherit;color:rgb(29,28,29);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;font-variant-ligatures:common-ligatures">V.  </div></div>