Research and Scholarship and filter by relying party

Tom Scavo trscavo at gmail.com
Tue Mar 4 16:39:57 EST 2014


On Tue, Mar 4, 2014 at 4:18 PM, Jeffrey Crawford <jeffreyc at ucsc.edu> wrote:
>
> On Tue, Mar 4, 2014 at 11:47 AM, Tom Scavo <trscavo at gmail.com> wrote:
>>
>> Current wisdom is that the
>> SP should be able to handle the lack of attributes:
>>
>> https://spaces.internet2.edu/x/m42KAQ
>> https://spaces.internet2.edu/x/xa6KAQ
>
> Well okay so if an SP doesn't even get NamedID it's supposed to handle that?

Yes, but why can't you release Transient or Persistent NameIDs by
default? There's no privacy leakage there.

> there are various reasons for controlling what our IdP allows logins to, the
> simplicity of simply saying that we don't support an SP unless it's
> authorized covers most if not all those reasons.

Seems like you're talking about campus policy (which is fine of
course, campuses can do anything they like) but in a cross-domain
scenario, authorization is not the IdP's responsibility. Your job is
to authenticate the user and provide attributes (or not, subject to
policy). The SP decides what to do next.

(Sorry, you asked about an InCommon use case, so I'm giving an
InCommon perspective.)

Tom


More information about the users mailing list