<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><font face="courier new, monospace">Jeffrey E. Crawford<br>ITS Application Administrator (IdM)<br>831-459-4365<br><a href="mailto:jeffreyc@ucsc.edu" target="_blank">jeffreyc@ucsc.edu</a></font><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Both pilots and IT professionals require training and currency before charging into clouds!<br></font></div><div><font face="courier new, monospace">---------------------------------------</font></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jan 29, 2016 at 1:20 PM, Tom Scavo <span dir="ltr"><<a href="mailto:trscavo@gmail.com" target="_blank">trscavo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Fri, Jan 29, 2016 at 4:04 PM, Jeffrey Crawford <<a href="mailto:jeffreyc@ucsc.edu">jeffreyc@ucsc.edu</a>> wrote:<br>
><br>
> On Fri, Jan 29, 2016 at 12:35 PM, Tom Scavo <<a href="mailto:trscavo@gmail.com">trscavo@gmail.com</a>> wrote:<br>
>><br>
</span><span class="">>> More generally, SAML2 Persistent NameID should be just fine. It can be<br>
>> difficult to deploy but if you already have it deployed, by all means<br>
>> use it. It has the best privacy preserving properties of any<br>
>> well-known identifier.<br>
><br>
> other than the fact some eduGain entities specifically have transient listed<br>
> first but I think they request attributes as well but I only spot checked.<br>
<br>
</span>The only way we'll truly ever be able to rely on requested attributes<br>
in metadata is by using meta-attributes:<br>
<a href="https://spaces.internet2.edu/x/QgOVBQ" rel="noreferrer" target="_blank">https://spaces.internet2.edu/x/QgOVBQ</a></blockquote><div><div class="gmail_default" style="font-family:courier new,monospace">​We do have filter configs that will honor ​requests, since the user has to consent anyway, but transient vs persistent is set in the relying party preference pragma, or it's read from the NameIDFormat order in the metadata. In either case the user doesn't by default get shown either transient or persistent on the consent page. As of today they would only see that eduPersonScopedAffiliation is sent.<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<span class=""><br>
> Does REFEDS R&S have more attributes than InCommon does? I'm sure it's<br>
> documented somewhere but I didn't find it quickly.<br>
<br>
</span>No, the attribute requirements are exactly the same.<br></blockquote><div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​Fair enough but has someone somewhere come up with a list of attributes that could be useful for the ones that request outside of R&S. The user still has to consent to the release in our case so we may want to consider them.<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
Tom<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div></div>