<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="Title" content="">
<meta name="Keywords" content="">
<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:12.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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hey FastFed<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Here are areas of further discussion from Darin’s draft. If any of the topics starts off a discussion here on the mail list, let’s fork the thread and rename the topic.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">We will start discussing this in our call next Wednesday.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">/Dick <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(1) Attributes - Descriptions & Mappings</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">There several instances in the proposal where a participant conveys information about the user attributes they vend/consume.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Discussion points:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">· The proposed identity provider metadata includes a description of “Supported Attributes”. The intent was for a provider to indicate what it <i>could</i> provide, so that services can halt the registration
if necessary attributes are missing. Does the group think this metadata would be used in practice, or it is unnecessary?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">· The service provider metadata allow the expression of which attributes are required vs optional for the service. The intent is to allow a human administrator to see which attributes will be released,
and to bulk-approve the release of user attributes for all members of the organization in advance, rather than asking each end-user to approve. Any concerns with this decision? And, is optional-vs-required a rich enough vocabulary to convey the needs, or is
additional information necessary.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">· The proposal is opinionated about differentiating between a “logical expression” of attributes vs. the “physical manifestation” of attributes. It requires consensus on the logical vocabulary (e.g.
everyone uses “displayName” to represent the displayable name of the user), but allows each service provider to define how to bind those attributes into SAML/OIDC messages.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">o The logical portion uses a structure based off SCIM. However, the SCIM specification does not currently define a mechanism to describe which SCIM attributes can be vended/consumed, and whether they are
required/optional. Any prior work in this area? Should this be part of FastFed, or should there be an independent extension to SCIM which FastFed leverages?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">o Binding the logical attributes onto the physical SAML/OIDC messages requires a mapping syntax. Similar to the previous question, should this be part of the FastFed spec or an independent extenstion to
SCIM? Is the proposed mapping syntax sufficient? <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt"> </span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(2) Metadata Format and Contents</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The FastFed proposal describes two configuration files: a public “Discovery” file, and a private “Metadata” file.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Questions for the group:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">· Any concerns about splitting the files?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">· Do they contain the right information? Is anything missing? Should anything in the private file be public?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">· The format is simple JSON key/values. OTTO has defined a richer metadata structure. Should FastFed apply a similar pattern?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">· Does anyone foresee future extensibility needs that cannot be met by the proposed format?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(3) Entitlements</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Some applications offer different profiles/roles that users can attain. The permissions to do so are sometimes represented in extended attributes on the user profile, inside the Identity Provider.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Custom attributes are generally in conflict with the FastFed goals because they require an administrator to define/configure additional data. However, the need for profile management still exists. Can FastFed
support these custom attributes without sacrificing usability? <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">If there is enough commonality in the representation of entitlements, it might be possible for FastFed to define a mechanism for Service Providers to declare the set of profiles/roles that can be attained.
However, this is a slippery slope. Authorization rules become complicated very quickly. It is undetermined if this is possible or appropriate for FastFed to address.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(4) Credential Exchange</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">FastFed needs to distribute credentials to the IdP and SP so they can communicate with each other. OAuth tokens are nice, but there is no existing OAuth grant type that aligns with the FastFed needs. An unorthodox
flow is proposed. Does anyone have concerns with the flow and wish to suggest alternative strategies?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(5) Certificate/Key Rotation</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The initial configuration of SSO is just the beginning. There is ongoing responsibility for certificate/key rotation. With the goal of “simple federation”, how opinionated should FastFed be at specifying the
rotation requirements to be FastFed compliant? For example, is it practical to require that all parties support SAML certificate rotation without downtime?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(6) User Provisioning/Deprovisioning</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">May apps require user provisioning. With the goal of “simple federation”, FastFed needs a way for service provider to express their desired provisioning mode so that FastFed Compliant providers can make it
“just work”. There should be a small number of easily understood modes. What are they? Two candidates are “None” and “JIT”. Perhaps also “Preprovisioned”. Are those sufficient?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Deprovisioning is more complicated. Feedback from a large enterprise player is that SCIM’s boolean “active” flag is insufficient to represent their user modes and deprovisioning requirements. They implement
custom deprovisioning logic for each application. Let’s review this feedback and consider whether FastFed can meet the deprovisioning requirements.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(7) Endpoints on the public internet</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The flows described in this document require that an SP be able to communicate programmatically with the IdP. For example, to load the FastFed Metadata configuration, refresh OAuth tokens, and rotate keys.
Many existing installations of SAML IdPs exist in private networks with firewall restrictions. They may not be able to call (or be called) via endpoints on the public Internet. This has not mattered in the past because SAML relied on the user_agent as a data
carrier.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Question for the group – Is this a serious roadblock that needs to be considered? If so, it may be necessary to define a FastFed flow that performs the registration handshake through the user_agent via HTTP
POSTS, and negates the need for public endpoints. This profile may only support a limited subset of FastFed functionality.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(8) Terminology</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">FastFed is unique in that it spans three existing specs, each with unique terminologies. Does FastFed foist a 4<sup>th</sup>terminology on the world? Any suggestions for that terminology?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">(9) Threat Model Review</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">As the specification gets closer to finalization, a threat model will be performed. Let’s review the results with a critical eye.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</body>
</html>