Skip to Content.
Sympa Menu

interfed - [inc-interfed] Apr 16 agenda / Apr 9 notes

Subject: Interfederation

List archive

[inc-interfed] Apr 16 agenda / Apr 9 notes


Chronological Thread 
  • From: Jim Basney <>
  • To: Interfederation TAC Subgroup <>
  • Subject: [inc-interfed] Apr 16 agenda / Apr 9 notes
  • Date: Tue, 9 Apr 2013 14:14:31 -0500
  • Authentication-results: sfpop-ironport03.merit.edu; dkim=neutral (message not signed) header.i=none
  • Openpgp: id=0A33BE15; url=http://www.ncsa.illinois.edu/~jbasney/pgp.asc

Proposed agenda for Apr 16 call:

* Update on LIGO SP + UK IdP pilot
* Starting on lessons learned doc:
LIGO Wiki, I2 Spaces Wiki, Shibboleth.net, TERENA SP
* other items?

Minutes from Apr 9 call:

attending: JimB, TomS, IanY, ScottK, SteveC, MarkS, JohnK, ChrisP

LIGO SP ready to consume metadata aggregate feed.
One remaining issue with extensions element. Steve made a quick fix.
LIGO willing to take over operation of the aggregate feed.
Static metadata aggregate OK for Scott for next month.
Steve will work on updating aggregate creation process to fix
extensions element, sign aggregate, and set ValidityUtil value.
ScottK will then ask Cardiff colleagues to test.
Ian met with UK helpdesk.
Desired IdPs list is: Sheffield, Warwick, Birmingham, Cambridge, and
Glasgow.
Ian recommends proceeding with Glasgow's test IdP.
With ChrisP joining us, how about expanding LIGO pilot to
Canadian Access Federation (CAF)?
LIGO postdoc users at U Toronto and Waterloo.
Talked in the past about LIGO joining CAF. Also I2 spaces joining CAF.
U Toronto could be do-able. Waterloo are CAF members.
Maybe also UVic and Calgary?
LIGO SP could join eduGAIN via CAF (on a pilot basis)?
Interesting idea, but LIGO should probably focus on
joining eduGAIN via InCommon.
Is LIGO maintaining separate metadata registrations?
Yes, LIGO is federating with KAGRA IdP (Japan).
Where is authoritative version of LIGO SP metadata?
Will know more when working with IDEM (hopefully in a few weeks).
Scott thinks GakuNin pulling SP metadata from InCommon.
Future InCommon work would be to incorporate publisher schema and
include registrationAuthority="https://incommon.org"; and
publisher="https://incommon.org"; in InCommon metadata.
2nd draft of UK FTS: http://dl.dropbox.com/u/236274/FTS-1.4-20130407.pdf
Discussion of DisplayName uniqueness.
Gateways (i.e., social-to-SAML) could be problematic (see mailing list).
What are requirements on org name elements?
Just publish what we do or set minimum standards?
For UK federation, OrganizationName is name of org that registered the
entity (i.e., legally responsible party). OrganizationDisplayName is
for human consumption to say what the service is. For IdPs,
OrganizationDisplayName would identify communities represented.
mdui:DisplayName is supposed to replace OrganizationDisplayName.
Currently UK doesn't check that DisplayName and
OrganizationDisplayName are identical. It would be desirable for them
to be identical, since non-mdui-aware discovery services will use
OrganizationDisplayName.
LIGO is a Shibboleth shop, using embedded discovery service
(mdui-aware). On Shibboleth SP, LIGO setting legacyOrgNames=true
to use OrganizationDisplayName if mdui:DisplayName not present.
LIGO baseline requirements:
* have some way of knowing if discovery service name collision may occur
(example: Tsinghua University)
* look in metadata to know entity really is who you're looking for
i.e., OrganizationName="Cardiff University" really is Cardiff
UK toolchain ensures that all OrganizationDisplayNames are unique.
May not always be able to fix name collisions at the source across
federations. In this case would need some DisplayName mapping
(entityIDs->displayNames) in the aggregator.
Should home federation provide some assurance about registration
processes of external federation entities in aggregate?
ScottK doesn't expect InCommon to do this. LIGO willing to check
registration policies of other federations they rely on.



Archive powered by MHonArc 2.6.16.

Top of Page