Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] status update, creating combined metadata file

Subject: Interfederation

List archive

Re: [inc-interfed] status update, creating combined metadata file


Chronological Thread 
  • From: Tom Scavo <>
  • To: Interfederation TAC Subgroup <>
  • Subject: Re: [inc-interfed] status update, creating combined metadata file
  • Date: Mon, 25 Feb 2013 14:29:25 -0500
  • Authentication-results: sfpop-ironport03.merit.edu; dkim=pass (signature verified)

On Mon, Feb 25, 2013 at 11:45 AM, Cantor, Scott
<>
wrote:
>
> I don't understand your resistance to simply creating a republishing
> agreement rather than creating custom feeds.

I'm suggesting we do both.

> How is that less work?

I didn't say that it was. Including "foreign" entity descriptors in
the InC aggregate conflates (or dilutes) the trust semantics of the
InC metadata signing key. InC Ops makes (implicit) guarantees with
respect to InC entity descriptors in metadata. (Do we need to
enumerate them?) We can't make the same claims about "foreign" entity
descriptors so I think we have to introduce a new signing key, that
is, a second signing key with different semantics. Custom metadata
aggregates are not a strict requirement but they do isolate the
entities that new key implicitly covers.

Btw, at this time we can only aggregate IdP metadata. SP metadata
aggregation is functionally equivalent to proxying IdP attributes OUT
of the InCommon Federation. That can't be done without a much larger
policy discussion, I'm afraid.

> Why impose a scalability barrier given that if the attribute issue were
> ever to be solved, you'd have added yet another opt-in barrier that would
> take its place?

That may be a good reason to favor packaging all IdPs in a single file
but it doesn't change my PoV about a new signing key.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page