<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 4, 2014 at 1:39 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"><div class="">On Tue, Mar 4, 2014 at 4:18 PM, Jeffrey Crawford <<a href="mailto:jeffreyc@ucsc.edu">jeffreyc@ucsc.edu</a>> wrote:<br>
><br>
> On Tue, Mar 4, 2014 at 11:47 AM, Tom Scavo <<a href="mailto:trscavo@gmail.com">trscavo@gmail.com</a>> wrote:<br>
>><br>
</div><div class="">>> Current wisdom is that the<br>
>> SP should be able to handle the lack of attributes:<br>
>><br>
>> <a href="https://spaces.internet2.edu/x/m42KAQ" target="_blank">https://spaces.internet2.edu/x/m42KAQ</a><br>
>> <a href="https://spaces.internet2.edu/x/xa6KAQ" target="_blank">https://spaces.internet2.edu/x/xa6KAQ</a><br>
><br>
> Well okay so if an SP doesn't even get NamedID it's supposed to handle that?<br>
<br>
</div>Yes, but why can't you release Transient or Persistent NameIDs by<br>
default? There's no privacy leakage there.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'courier new',monospace">This particular case is more of a support issue than being concerned about releasing attributes. By listing relying parties we get errors for unsupported apps, as opposed to what look like valid logins. Lot of history behind that at this institution.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> there are various reasons for controlling what our IdP allows logins to, the<br>
> simplicity of simply saying that we don't support an SP unless it's<br>
> authorized covers most if not all those reasons.<br>
<br>
</div>Seems like you're talking about campus policy (which is fine of<br>
course, campuses can do anything they like) but in a cross-domain<br>
scenario, authorization is not the IdP's responsibility. Your job is<br>
to authenticate the user and provide attributes (or not, subject to<br>
policy). The SP decides what to do next.<br>
<br>
(Sorry, you asked about an InCommon use case, so I'm giving an<br>
InCommon perspective.)<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'courier new',monospace">Understood and perhaps it should be looked at again but this all started because of the policies of how we utilize Shibboleth and InCommon. We like the idea of RandS and want to support it, now it's a question about how to best do that with the existing self imposed restrictions.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><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>