Interfederation

[John Krienke <>]

Agenda looks good to me, Jim.

If I can frame the right question about "good standing" below, it might be:
From the SP's perspective, what assurances are needed to trust an external 
(external to the SP's home federation) IdP?

These assurances should be expressed in the federation-to-federation agreement 
about the nouns (org, IdP endpoints, keys, etc expressed in IdP md) and verbs 
(its behavior).

For discussion.

john.


On 3/5/13 12:24 PM, Jim Basney wrote:
> Hi,
>
> What should be on the agenda for our interfed call today?
>
> https://spaces.internet2.edu/display/incinterfed
>
> I think Paul Caskey will lead a discussion about the current status of
> the Quilt work.
>
> Then unless you propose other agenda items, I suggest we spend the
> remaining time on refining our canonical interfederation use case and
> identifying the hurdles we should tackle in the near term to achieve
> some initial success with this use case.
>
> I think the use case is:
>
> An InCommon SP (example: LIGO wiki) accepts authentication from both
> "international" IdPs (i.e., IdPs in other national federations) and
> InCommon IdPs, where:
>
> * The SP doesn't need to sign agreements with federations
>    other than InCommon.
>
> * The SP gets all IdP metadata from InCommon.
>
> * The SP registers its metadata with InCommon and doesn't
>    need to separately send its metadata elsewhere.
>
> I suggest we put the inverse use case ("international" SP with InCommon
> IdP) on the back burner at least for today.
>
> Topics include:
>
> * What are the minimal attribute requirements for
>    this use case? Just persistent user identifier?
>
> * What are the minimal federation-to-federation agreements
>    needed for this use case?
>
>    - Permission for federations to re-publish entities
>      from each other's metadata.
>
>    - Agreement that federations at least verify DNS ownership
>      for registered entities. Is any "good standing" criteria
>      besides this truly required?
>
> * Can we keep entity categories off the table for this initial use case
>    and deal with attribute release the old way?
>
> * Can we keep LOA off the table for this initial use case?
>
> -Jim