Interfederation

[Ian Young <>]

On 1 Apr 2013, at 21:51, Jim Basney 
<>
 wrote:

> The doc proposes registrationAuthority="https://incommon.org"; for
> InCommon's entities. Maybe we could make a proposal to InCommon TAC to
> formally adopt this value. Not saying InCommon would start including it
> in metadata anytime soon. Just saying InCommon could decide on what the
> value should be as a small step forward (if it's not decided already).

That particular value was made up in a quick exchange of e-mail with Tom 
Scavo as a reasonable first guess.  The table on page 14 does indicate that 
everyone else (except the Germans) have gone for http:// URIs rather than 
https:// ones, though, so it may be worth thinking about changing to http://. 
 I can't see any advantage to the https:// form for a URI, and it is of 
course one character longer…

I agree that having a value nailed down would be a forward step.

> I think InCommon satisfies the following:
> 
> "Entity owners registering metadata containing <shibmd:Scope> elements
> MUST demonstrate that each domain used is either owned by them, or that
> specific permission has been given to them to use the domain for the
> purpose of registering the entity. Federation partners are required to
> have broadly similar registration practices around the domain names
> registrants are permitted to use in <shibmd:Scope> elements."
> 
> - and -
> 
> "Federation partners are required to have broadly similar registration
> practices around the domain names registrants are permitted to use in
> http-scheme and https-scheme URIs used as entityID values."

My intention was certainly to write down criteria which InCommon would 
already meet, without being too detailed about them.

> I see that UK federation gives some flexibility to federation partners
> around the <Organization> element:
> 
> "The contents of the <Organization> element in metadata for imported
> entities is entirely determined by the originating registrar's
> registration practices."
> 
> Though earlier the doc describes an intention to "provide a comparable
> level of technical trust in imported metadata as for local metadata" so
> it's still valuable to compare InCommon practices around the
> <Organization> element with Section 3.9 of the UKFTS doc and see how
> that compares with LIGO needs.

I agree.  I think most of the national federations will turn out to be doing 
broadly similar things around <Organization>, but didn't want to rule out the 
possibility of something like REEP where the contents of that element might 
be self-asserted.  In cases like that, what will be important is that the 
relying party can tell (from the registrationAuthority) what the rules are, 
and (from a combination of that and the entityID) who to complain to.

> Other things I found particularly interesting
> (if I understood correctly):
> 
> UK federation uses a single key to sign multiple metadata aggregates.

Yes, all our aggregates have equivalent semantics (and almost all of them 
have the same entities in them) so I'm not worried about substitution 
attacks.  I think the worst outcome of a substitution attack is a DoS (e.g., 
if you force feed an end entity the export aggregate instead of what it's 
expecting) but if you can do the required DNS poisoning then I think a DoS is 
a given anyway.

> Entities owned by UK federation members "in good standing" are labeled
> with <ukfedlabel:UKFederationMember/>.

Yes (but only in the aggregates consumed by federation members).

The intention is that this should eventually become equivalent to 
RegistrationInfo/@registrationAuthority == "http://ukfederation.org.uk";, once 
we get to the point where the practice of that registrar is only to register 
entities belonging to UKf members.  At the present there is one exception to 
this (the Internet2 Spaces wiki), but in the long run I'd hope to replace the 
custom element.  That's part of the reason it's not present in the export 
aggregate.

> UK federation members can self-assert <ukfedlabel:AccountableUsers/>.
> (How does this compare with InCommon Bronze, I wonder.)

It's probably not very comparable, and certainly much less detailed.

See section 6 of 
http://www.ukfederation.org.uk/library/uploads/Documents/rules-of-membership.pdf

The other problem with it is that it applies to the whole IdP, which means 
that (e.g.) you can't have any anonymous users on such an IdP, even if you 
make appropriate statements about them.  This whole area is definitely 
something we can improve on; something like a self-asserted Bronze with 
appropriate changes for UK/EU law would make sense here.

> Non-production (and imported) IdPs have <wayf:HideFromWAYF/>
> (planned to be replaced by an entity category).

Imported IdPs are at present always marked that way, just to minimise 
surprises.

Non-production IdPs are *often* marked that way, but it's not guaranteed.  
Likewise, production IdPs *may* be marked, although it's very uncommon.

I think there's some mileage in standardising something in this area.  My 
current position (and I have gone back and forward on this since I invented 
HideFromWAYF) is that a functional tag meaning "I should be less 
discoverable" is better for this purpose than something with semantics like 
"I am a test entity" (from which you'd then deduce the functional 
implications).  You don't have to hang around very long in the eduGAIN 
mailing lists to learn how wide the different definitions of "test entity" 
are.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature