<html xmlns:v="urn:schemas-microsoft-com:vml" 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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
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.EmailStyle20
{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;}
/* List Definitions */
@list l0
{mso-list-id:67653953;
mso-list-type:hybrid;
mso-list-template-ids:-363584706 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:387656397;
mso-list-template-ids:-2066457268;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2
{mso-list-id:1243219637;
mso-list-template-ids:-268531502;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Really appreciate all the feedback. (And sorry it took so long to reply). It definitely called out a couple clarifications to make. I think I can color in the reasoning for some of the decisions where communities may continue having divergant
practices. Let’s see if we can get to common ground.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Before addressing the specifics, I’ll start with general context. We had a few tenets going into the working group. Hope these help illuminate.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Tenet 1) Solve the enterprise pain points (but don’t preclude usage in other domains)</b><b><o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Despite relying on the same standards, enterprise and higher education have historically diverged in their application. This is natural, as each has unique constraints. That led the education/research community into ecosystems such as InCommon
and the eduPerson schema, whereas the enterprise landscape is... well, Wild West. Anyone can launch a SaaS app into the world. Anyone can use it with a credit card. There is no common schema. Anything that causes abandonment is ruthlessly cut. The net result
is that enterprise tends to use simple subsets of the protocols, with a limited number of adhoc user attributes. Maybe a name and email. Sign-in usually occurs with an email address or phone number. When extended attributes are needed, they tend to be enterprise
specific, like Cost Center. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Interoperability is a lot harder in this ecosystem. FastFed aimed to solve this problem.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In the beginning, participants from the education/research space were questioning what we were solving. The original answer was “This isn’t for you”. However, upon deeper conversation with experts in the community via forums such as the
Internet Identity Workshop, it was determined that some bits could be valuable. For example, the easy user experience. To allow other communities to leverage this, FastFed offers extensibility via Profiles.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The BasicSaml profile included in this spec is for the enterprise community. It would be fantastic if other communities defined their own preferences. For example, a FastFed InCommon SAML profile that referenced existing practices by that
community. Similarly, you may want to consider an eduPerson extension to SCIM if that protocol looks useful.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">FastFed allows implementors to support any number of these profiles in parallel.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Tenet 2) Be additive, not transformative</b><b><o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To succeed, FastFed needs to rely on seductive adoption in the enterprise landscape. There is no regulatory force for change. To succeed, the ease of implementation was a key consideration. For that reason, we sought to avoid wholesale
changes to existing implementations. Instead, we aimed to be mostly additive. E.g. Adding a new handshake atop what exists, but not forcing people to rewrite their existing SAML and SCIM endpoints.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As a result, the FastFed Profiles largely represent the current practices of the enterprise community. While we may wish those practices were different, that ship has largely sailed. We don’t believe it’s FastFed’s place to mandate a wholesale
migration to different SAML practices, nor do we believe that is likely to succeed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Rather, where the interop profiles require changes, they tend to be small nudges that have big returns on value. E.g. how to include multiple keys for certificate rotation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Tenet 3) Put the burden on IdPs<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If any portions of the spec unavoidably require a fair amount of effort for implementation, we leaned toward putting that burden on the IdPs. The reason for this is that, in the enterprise space, there exists a smaller number of IdP venders
(when compared to the thousands of SaaS applications). They are in a better position to invest in the work and see that return.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Tenet 4) Solve the 80% case<o:p></o:p></b></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">FastFed was never going to be for everyone, even in the enterprise space. We prefer to deliver an easy user experience for the 80% of scenarios that can take advantage of it, rather than overcomplicate the spec (and slow down adoption)
to handle the long tail.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Tenet 5) Use SCIM as the lingua franca<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The enterprise community lacked consensus on a standard user schema. Most applications just made up their own. To align on interoperability, FastFed went with SCIM as the grammar to reference user attributes. This is true even if the application
doesn’t run a SCIM server. For example, if the app relies upon JIT provisioning, it will still use the SCIM schema grammar to describe the user attributes. There are no references to eduPerson (although if the higher education community wanted a similar schema,
they could define eduPerson extensions for SCIM).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Other Materials<o:p></o:p></b></p>
<p class="MsoNormal">There’s a 20 minute YouTube video that gives a quick overview of the problem statement; including the most common question, which is why this isn’t solved already by OpenID Connect.<br>
<a href="https://www.youtube.com/watch?v=ucQl5p6sa4A">https://www.youtube.com/watch?v=ucQl5p6sa4A</a><o:p></o:p></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal">There’s also a set of use cases in the FastFed repo that dig deeper into the scenarios that FastFed is solving. (We started with Scenario 1).<o:p></o:p></p>
<p class="MsoNormal"><a href="https://bitbucket.org/openid/fastfed/src/master/scenarios/">https://bitbucket.org/openid/fastfed/src/master/scenarios/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">------<o:p></o:p></p>
<p class="MsoNormal">I hope that helps illuminate some context. Given that foundation, here are answers to the specific questions.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><i>>> Violates the SAML 2.0 standard by misusing the persistent nameID format<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I apologize, but this was just a copy-and-paste error. And, I thank you for catching it.<o:p></o:p></p>
<p class="MsoNormal">The intended format was “unspecified”. I recognize this may raise other concerns, so I’ll explain the reasoning (and where we can change). For the most part, the enterprise community just doesn’t care. It ignores the type. The expected
inputs are documented elsewhere. If the wrong input is provided, the federation simply doesn’t work.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Since FastFed is opinionated about requiring the SCIM username as the nameId (I’ll come to that next), we could technically call the format “reassignable”. If that was the only blocker to spec approval, that’s an easy change. But, again,
most applications just ignore this.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><i>>> Using email address as a user identifier is a practice that is known to be problematic<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There’s some trickiness to this one. A couple factors to call out:<o:p></o:p></p>
<p class="MsoNormal">1/ I’ll note that the SCIM username isn’t necessarily an email, but often is. Hence, that was used in the example. But, username != email with any guarantee.<o:p></o:p></p>
<p class="MsoNormal">2/ There is no existing persistent identifier in the enterprise ecosystem that all the parties agree upon. The closest is the SCIM externalID, which is the persistent identifier within the IdP that is optionally passed into the Application.
But, than can change if an organization migrates to a new IdP provider.<o:p></o:p></p>
<p class="MsoNormal">3/ When it comes to SaaS applications, the majority of apps already use email or phone as the identifier. That ship has sailed.<o:p></o:p></p>
<p class="MsoNormal">4/ FastFed needs to support JIT scenarios, as well as scenarios where the user was pre-provisioned prior to the SAML authentication. Just a callout to keep in mind.<o:p></o:p></p>
<p class="MsoNormal">5/ FastFed is targeting enterprises, and enterprises recycle usernames less often than a social provider like Yahoo. Nonetheless, FastFed encourages mechanisms such as SCIM provisioning to keep applications in sync should it occur. You’ll
see the SCIM profile has recommendations for username recycling.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">FastFed threads this needle by doing the following:<o:p></o:p></p>
<p class="MsoNormal">* Specifying the SCIM username as the subject. Because, it is the only mutually shared value that was guaranteed to be defined, and could also serve as an identifier. And, in fact, is how most SSO setups operate today in the enterprise
space.<o:p></o:p></p>
<p class="MsoNormal">* Passing the SCIM externalId in the attribute, for additional robustness by those who support it. That’s the persistent identifier within the given IdP.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Given the constraints of the enterprise landscape, is there a different approach to recommend? One that also stays within the original tenets?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><i>>> Abuses unspecified NameFormat in mapping attributes from SCIM, does not use the proper official names for these attributes (inetOrgPerson).<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is how the enterprise landscape already operates, and there is not consensus that inetOrgPerson is the proper official name in this ecosystem. FastFed improves the status quo by aligning on SCIM as a shared grammar for user schema
and attribute names. The binding into SAML is aimed at the audience who wishes to continue using JIT capabilities they already possess, whereas FastFed highly encourages the use of SCIM provisioning for anything more complicated. But, again, these are profiles
for an enterprise audience. Other communities can specify different ones.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><i>>> Claims that SAML doesn’t support provisioning of groups is incorrect.<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is my own fault for unclear language. The intent was to say that the FastFed BasicSaml profile doesn’t allow inclusion of groups (not that SAML doesn’t support it). In this particular FastFed Profile, anyone that wants group memberships
must use the SCIM provisioning channels. <o:p></o:p></p>
<p class="MsoNormal">If another community wishes to define an alternative profile that supports groups, that’s OK too.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><i>>> “No standard mechanism for an identity provider and application provider to directly exchange metadata required by existing standards” is incorrect.<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The following sentence after that clarifies the context. A human being is required to act as a data bus between the providers, downloading/uploading the metadata files between the parties. The key phrase in the sentence is “directly exchange”,
as the parties can’t talk to each other directly. Can clarify that language if it’s causing confusion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><i>>> SAML 2.0 has OpenID Connect/OAuth-compatible identifiers that should be used (admittedly, they are new, but all reasonably well-implemented SAML software should be able to support them if configured to do so)<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To be honest, I wasn’t sure how to apply this. And, in the enterprise space, most SAML implementations are not reasonably well implemented : )<o:p></o:p></p>
<p class="MsoNormal">Given everything discussed so far about the constraints and tenets that FastFed is operating within, is there a specific recommendation for an alternative identifier?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">---------------<o:p></o:p></p>
<p class="MsoNormal">I apologize for this long response, but hopefully it helps illuminate some of the choices made. Given everything discussed so far, does it lead to any new questions or alternative takes on the spec?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Darin<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>Nicholas Roy <roy.nicholas@gmail.com><br>
<b>Date: </b>Wednesday, May 20, 2020 at 1:43 PM<br>
<b>To: </b>Andrew Jason Morgan <morgan@oregonstate.edu><br>
<b>Cc: </b>Openid-specs-fastfed <openid-specs-fastfed@lists.openid.net><br>
<b>Subject: </b>RE: [EXTERNAL] [Openid-specs-fastfed] FastFed SAML Feedback<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr style="height:15.25pt">
<td width="1123" valign="top" style="width:842.35pt;border:solid #ED7D31 1.5pt;padding:0in 5.4pt 0in 5.4pt;height:15.25pt">
<p><strong><span style="font-family:"Calibri",sans-serif;color:black;background:#FFFF99">CAUTION</span></strong><span style="color:black;background:#FFFF99">: This email originated from outside of the organization. Do not click links or open attachments unless
you can confirm the sender and know the content is safe.</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Thank you for following up, Andy. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If there are other questions, Andy and I, and other from the various SAML groups, can try to answer them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nick<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, May 14, 2020 at 12:33 PM Andrew Jason Morgan <<a href="mailto:morgan@oregonstate.edu">morgan@oregonstate.edu</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Mike (and others),<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">I've been participating in several working groups related to SAML deployment with Nick.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Let me quote the relevant documents first.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">FastFed Basic SAML Profile 1.0 - draft 02, section 4.1.1 states:<o:p></o:p></span></p>
</div>
<div>
<blockquote style="border:none #C8C8C8 1.0pt;border-left:solid #C8C8C8 2.25pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666">The Subject element MUST contain a NameID with the following properties:<o:p></o:p></span></p>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:#666666;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">A Format set to "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"<o:p></o:p></span></li><li class="MsoNormal" style="color:#666666;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">A value populated with the SCIM userName.<o:p></o:p></span></li></ul>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">and gives an example value of "<a href="mailto:babs@example.com" target="_blank">babs@example.com</a>".<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">The SCIM userName attribute is defined in RFC7643 as:<o:p></o:p></span></p>
</div>
<div>
<blockquote style="border:none #C8C8C8 1.0pt;border-left:solid #C8C8C8 2.25pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> userName<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> A service provider's unique identifier for the user, typically<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> used by the user to directly authenticate to the service provider.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> Often displayed to the user as their unique identifier within the<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> system (as opposed to "id" or "externalId", which are generally<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> opaque and not user-friendly identifiers). Each User MUST include<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> a non-empty userName value. This identifier MUST be unique across<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> the service provider's entire set of Users. This attribute is<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"> REQUIRED and is case insensitive.<o:p></o:p></span></p>
</blockquote>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">SAML Core 2.0 (<a href="https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf" target="_blank">https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf</a>)
section 8.3.7 defines the qualities of a persistent NameID as:<o:p></o:p></span></p>
</div>
<div>
<blockquote style="border:none #C8C8C8 1.0pt;border-left:solid #C8C8C8 2.25pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:12.5pt;font-family:"Arial",sans-serif;color:#666666">URI:</span><span style="font-size:12.5pt;font-family:"Courier New";color:#666666">urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#666666"><br>
Indicates that the content of the element is a persistent opaque identifier for a principal that is specific to an identity provider and a service provider or affiliation of service providers. Persistent name identifiers generated by identity providers MUST
be constructed using pseudo-random values that have no discernible correspondence with the subject's actual identifier (for example, username). The intent is to create a non-public, pair-wise pseudonym to prevent the discovery of the subject's identity or
activities.<o:p></o:p></span></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><a href="mailto:babs@example.com" target="_blank">babs@example.com</a> cannot be a persistent NameID value because it:<o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">is NOT opaque<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">is NOT generated from a pseudo-random value<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">DOES correspond (in fact, is) the subject's actual identifier<o:p></o:p></span></li></ul>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">I don't think you can reasonably interpret the SCIM userName as meeting the requirements of a persistent NameID. SCIM mentions that userName differs from "id", and
"id" has semantics much closer to a persistent NameID. Please note that I am not as familiar with SCIM as SAML, so my comments regarding SCIM are only superficial.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">As an operator of a SAML Identity Provider, I frequently see requests (mostly from vendors) wanting me to send an email address as a persistent NameID. I refuse
to violate the spec and common sense. Even if we ignore the other semantics of a persistent NameID, email addresses are not persistent. At most institutions, email addresses can change for various reasons because they are typically based on a person's name.
When we release persistent NameIDs, they are generated from an internal IAM generated unique id value.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Furthermore, the NameID is a poor choice to convey a user identifier because its use is so constrained. When crafting the requirements in the SAML V2.0 Deployment
Profile for Federation Interoperability<a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html" target="_blank"> (https://kantarainitiative.github.io/SAMLprofiles/saml2int.html</a>), we considered all the available methods of representing user
identifiers in SAML. We decided to require support for the SAML V2.0 Subject Identifier Attributes Profile Version 1.0 (<a href="https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.pdf" target="_blank">https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.pdf</a>).
This profile defines 2 SAML attributes that are almost identical to the OIDC identifiers. See sections 3.1.3 and 4.1.3 of saml2int.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Thank you for the opportunity to participate!<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div id="gmail-m_8528664953913150228Signature">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Andy Morgan</span><span style="font-size:12.0pt;font-family:"Courier New";color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Identity & Access Management</span><span style="font-size:12.0pt;font-family:"Courier New";color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Oregon State University</span><span style="font-size:12.0pt;font-family:"Courier New";color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<div id="gmail-m_8528664953913150228divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Openid-specs-fastfed <<a href="mailto:openid-specs-fastfed-bounces@lists.openid.net" target="_blank">openid-specs-fastfed-bounces@lists.openid.net</a>> on behalf of
Mike Jones via Openid-specs-fastfed <<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank">openid-specs-fastfed@lists.openid.net</a>><br>
<b>Sent:</b> Thursday, May 14, 2020 8:43 AM<br>
<b>To:</b> Nicholas Roy <<a href="mailto:roy.nicholas@gmail.com" target="_blank">roy.nicholas@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank">
openid-specs-fastfed@lists.openid.net</a> <<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank">openid-specs-fastfed@lists.openid.net</a>><br>
<b>Subject:</b> Re: [Openid-specs-fastfed] FastFed SAML Feedback</span> <o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:#002060">It’s my hope that the working group members will now have a dialog with Nick and the others behind this feedback to figure out how to address the feedback.</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:#002060"> </span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:#002060">I’ll start this off by asking for more specifics on 1. How is the spec misusing the persistent nameID format and what change would those that wrote this feedback suggest to address this
issue, Nick?</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:#002060"> </span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:#002060"> -- Mike</span><o:p></o:p></p>
<p style="margin:0in;margin-bottom:.0001pt"><span style="color:#002060"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p style="margin:0in;margin-bottom:.0001pt"><b>From:</b> Openid-specs-fastfed <<a href="mailto:openid-specs-fastfed-bounces@lists.openid.net" target="_blank">openid-specs-fastfed-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Nicholas Roy via Openid-specs-fastfed<br>
<b>Sent:</b> Tuesday, May 12, 2020 2:57 PM<br>
<b>To:</b> <a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank">
openid-specs-fastfed@lists.openid.net</a><br>
<b>Subject:</b> [Openid-specs-fastfed] FastFed SAML Feedback<o:p></o:p></p>
</div>
<p style="margin:0in;margin-bottom:.0001pt"> <o:p></o:p></p>
<div>
<div>
<p style="margin:0in;margin-bottom:.0001pt">Hi,<o:p></o:p></p>
<div>
<p style="margin:0in;margin-bottom:.0001pt"> <o:p></o:p></p>
</div>
<div>
<p style="margin:0in;margin-bottom:.0001pt">I've been asked to provide feedback on the FastFed drafts. The following is a roughly compiled, likely incomplete list, which is the result of review of the FastFed SAML profile by some people within the SAML deployment
and standards communities I work with. I am acting as a relay. I've requested that others from these groups also join this list, to enable a dialogue about the issues and their potential resolutions.<o:p></o:p></p>
</div>
<div>
<p style="margin:0in;margin-bottom:.0001pt"> <o:p></o:p></p>
</div>
<div>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:47.25pt;margin-bottom:.0001pt;vertical-align:baseline">
<span style="color:black">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="font-family:"Arial",sans-serif;color:black">Violates the SAML 2.0 standard by misusing the persistent nameID format</span><o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:47.25pt;margin-bottom:.0001pt;vertical-align:baseline">
<span style="color:black">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="font-family:"Arial",sans-serif;color:black">Abuses unspecified NameFormat in mapping attributes from SCIM, does not use the proper official names for these attributes (inetOrgPerson). This scheme is not interoperability-safe since it is
string-based and not oid-based.</span><o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:47.25pt;margin-bottom:.0001pt;vertical-align:baseline">
<span style="color:black">3.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="font-family:"Arial",sans-serif;color:black">Claims that SAML doesn’t support provisioning of groups is incorrect.</span><o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:47.25pt;margin-bottom:.0001pt;vertical-align:baseline">
<span style="color:black">4.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="font-family:"Arial",sans-serif;color:black">“No standard mechanism for an identity provider and application provider to directly exchange metadata required by existing standards” is incorrect. See:
<a href="https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html#_metadata_and_trust_management" target="_blank">
https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html#_metadata_and_trust_management</a> and
<a href="https://kantarainitiative.github.io/SAMLprofiles/saml2int.html#_metadata_and_trust_management" target="_blank">
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html#_metadata_and_trust_management</a>. These methods are currently in use by tens of thousands of Identity Providers and Service Providers globally, just within the Research and Education community:
<a href="https://technical.edugain.org/status" target="_blank">https://technical.edugain.org/status</a>.</span><o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:47.25pt;margin-bottom:.0001pt;vertical-align:baseline">
<span style="color:black">5.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="font-family:"Arial",sans-serif;color:black">Using email address as a user identifier is a practice that is known to be problematic (see also:
<a href="https://celeretech.com/blog/yahoo-begins-recycling-e-mail-accounts/" target="_blank">
https://celeretech.com/blog/yahoo-begins-recycling-e-mail-accounts/</a>)</span><o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:47.25pt;margin-bottom:.0001pt;vertical-align:baseline">
<span style="color:black">6.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="font-family:"Arial",sans-serif;color:black">SAML 2.0 has OpenID Connect/OAuth-compatible identifiers that should be used (admittedly, they are new, but all reasonably well-implemented SAML software should be able to support them if configured
to do so): <a href="https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html" target="_blank">
https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html</a></span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;vertical-align:baseline">
<span style="font-family:"Arial",sans-serif;color:black">Best Regards, </span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;vertical-align:baseline">
<span style="font-family:"Arial",sans-serif;color:black">Nick Roy</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>