Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] Apr 2 notes / Apr 9 agenda

Subject: Interfederation

List archive

Re: [inc-interfed] Apr 2 notes / Apr 9 agenda


Chronological Thread 
  • From: Tom Scavo <>
  • To: Interfederation TAC Subgroup <>
  • Subject: Re: [inc-interfed] Apr 2 notes / Apr 9 agenda
  • Date: Tue, 9 Apr 2013 16:32:58 -0400
  • Authentication-results: sfpop-ironport04.merit.edu; dkim=pass (signature verified)

On Tue, Apr 9, 2013 at 1:10 PM, Cantor, Scott
<>
wrote:
> On 4/9/13 12:53 PM, "John Krienke"
> <>
> wrote:
>>
>>If
>>this becomes a global practice, we could see dozens or hundreds of social
>>IdP
>>gateways, where the combination of Organization Display Name + MDUI
>>DisplayName
>>may be unique, but the MDUI DisplayName by itself is not. This seems to
>>place a higher bar on intelligent Discovery UI.
>
> Intelligent, ok, but psychic? There's not a lot you can do with ten IdPs
> all called the same thing. There's no user who's going to understand that.

Right, and that negative effect on usability is the bottom line. Any
metadata aggregate should enforce uniqueness on MDUI DisplayName. I
don't see how it can be any other way.

> But I think it's questionable to have a campus operated gateway registered
> as an IdP, personally. I don't see what that's meant to accomplish in the
> context of InCommon.

Well, I think it's safe to say your working definition of "InCommon
metadata" is fairly rigid. There are many entity descriptors in
InCommon metadata that don't fit your definition and I'm pretty sure
we want that trend to continue (I do, at least) so AFAICT we have two
choices: 1) we can use entity attributes to tag entities with various
characteristics, or 2) we can produce multiple metadata aggregates
containing groups of entities with similar characteristics. For
example, we can create a "CMU aggregate" that contains 2 IdPs (one a
campus-based social IdP) and 174 SPs, which is the totality of
entities registered by CMU. Presumably only CMU deployments would be
interested in consuming the CMU aggregate.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page