<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 12:35 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 29, 2016 at 3:17 PM, Jeffrey Crawford <<a href="mailto:jeffreyc@ucsc.edu">jeffreyc@ucsc.edu</a>> wrote:<br>
> Now that I've studied the preview metadata I'm starting to get the IdP ready<br>
> for eduGain. Hopefully without breaking existing InCommon stuff.<br>
<br>
</span>Thanks for being on top of this.<br>
<span class=""><br>
> 1. There is a point in the getting ready guide that says use entity<br>
> attributes instead of the urn:mace:incommon "Group" name. However the<br>
> preview has that still included.<br>
<br>
</span>It is there for backwards compatibility. It will never go away.<br>
<span class=""><br>
> For various reasons I'm trying to<br>
> distinguish between an InCommon identity, eduGain identity, and local<br>
> identity which has it's own group name. Is the following logic going to work<br>
> and be stable?:<br>
> (eduGain = group::urn:mace:incommon & (!attr::registerd-by-incommon))<br>
<br>
</span>When you disaggregate the metadata (as in per-entity metadata), the<br>
group name disappears, so anything based on it will break. So, no,<br>
don't rely it if you don't have to (and I don't think you have to). </blockquote><div> </div><div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​This may be an artifact of how I've got things configured currently, however if I only rely on the absence of "registered-by-incommon" I'll pick up​</div> <div class="gmail_default" style="font-family:courier new,monospace;display:inline">​our local metadata as well, which has yet another default release policy. Part of this config is in relying-party.xml (nameidPreference) and it has a "first match" behavior, so I need to be specific that id came from InCommon-metadata.xml and it is either registered-by-incommon or not (Several entities have no attributes).<br></div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Per-entity metadata is coming. IdPs will be the first to benefit.<br>
<span class=""><br>
> 2. There have been many discussions about what "identifier" is used in the<br>
> larger eduGain space. Since there is some local concern about releasing eppn<br>
> internationally, I'm planning on releasing persistant-id without eppn to<br>
> eduGain entities via nameIDFormatPrecedence and keep the current eppn +<br>
> transient-id combo in incommon. Do we risk large scale interoperability<br>
> issues with not releasing eppn for eduGain? I've seen many that have<br>
> transient as NameIDFormat listed first, and requested attributes, which we<br>
> will still honor via the consent page. But I'm worried there may be many<br>
> with transient requested and no AttributeRequests.<br>
<br>
</span>Are you talking about Research & Scholarship specifically? There you<br>
have no choice, ePPN is strictly required.<br></blockquote><div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​no​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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></blockquote><div> </div><div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​other than the fact some eduGain entities specifically have transient listed first​</div> <div class="gmail_default" style="font-family:courier new,monospace;display:inline">​but I think they request attributes as well but I only spot checked.​</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was going to "announce" this on the InCommon participants list on<br>
Monday but the Default Attribute Release wiki page has been totally<br>
overhauled due to community feedback:<br>
<a href="https://spaces.internet2.edu/x/RYH4Ag" rel="noreferrer" target="_blank">https://spaces.internet2.edu/x/RYH4Ag</a><br>
<br>
Take a look and tell me what you think. Comments welcome (but on the<br>
participants list please).<br>
<span class=""><br>
> 3. The reason we've been able to open the service up to wider SP's has been<br>
> the consent page. I have a pretty good handle on what can be "requested" on<br>
> the incommon side, but it looks like eduGain has requested attributes are<br>
> all over the map, does anyone have a list of "good to support" attributes<br>
> not covered by InCommon that should be considered in eduGain?<br>
<br>
</span>That's a hard question, best asked on the REFEDS mailing list, I<br>
think. That said, the easiest thing to do is craft a policy that<br>
releases any attribute in a bundle that you choose to define (like<br>
R&S). The composition of the bundle is the intersection of the<br>
attributes you support with the attributes you feel comfortable<br>
asserting to anyone (subject to consent).<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​Does REFEDS R&S have more attributes than InCommon does? I'm sure it's documented somewhere but I didn't find it quickly.<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> As a side note, we plan on treating all research and scholarship the same<br>
> way so we should be good there.<br>
<br>
</span>Good idea.<br>
<span class="HOEnZb"><font color="#888888"><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>
</font></span></blockquote></div><br></div></div>