Interfederation

[Ian Young <>]

On 7 Apr 2013, at 00:19, Tom Scavo 
<>
 wrote:

> comments and feedback

>       • [section 3.2.2] “particularly significant changes to an already 
> registered entity's metadata may result in a fresh registrationInstant 
> timestamp being recorded”
>               • You just made this up :-) AFAIK there’s nothing in the spec 
> that suggests that registrationInstant should be “refreshed” like this.

This is documentation of what we guarantee.  It's hard to guarantee that the 
"same" entity will always have the same registrationInstant for all time, so 
I'm not doing that.  If someone does something that I'd regard as an "update" 
but which involves essentially deleting and re-creating the entity, the 
registrationInstant might reflect that "second" registration rather than the 
original one.  It's hard to build tooling that doesn't have that behaviour, 
so I'm not guaranteeing that we will.

If you actually care about this (and I see no reason why you should, really) 
then I'd caution you that there are people out there who place too much 
emphasis on the SHOULD in the spec, and use it to justify populating this 
attribute with the current time.

If you don't trust our registrationInstant attribute, you're free to remove 
it before re-publication, as it is an optional attribute.  I don't see any 
benefit in such an approach.

>       • registrationAuthority ?= publisher
>               • Since the former is intended to resolve, perhaps the two 
> should be different?

As mentioned on the call, the spec says:

   It is RECOMMENDED that this be a URL that resolves to a human readable page
   describing the registrar authority (e.g., the registrar's home page).

I believe what we're doing meets the recommendation (which is only a 
recommendation in any case, not a requirement), as the URI resolves to the 
registrar's home page (in this case, the federation's home page, as we're 
choosing to make no public distinction).

It's clear that everyone else who has started using registrationAuthority has 
used the same reasoning.

>       • What is the purpose of including a (volatile) list of registrars in 
> section 3.2.2? Given the caveats noted in section 3.2.2, it might be best 
> to defer the maintenance of such a list to REFEDs.

I thought we had covered this on the call, but for the record:

* There is no registry for these values today.  It might be that one day such 
a registry exists, at which point I'll reconsider; until then, I consider it 
better to make the information I have available than not to do so.

* I think that it would be a good thing to have such a registry, and I'll 
probably bring that up to REFEDS as that seems like an appropriate place 
(eduGAIN would be another possibility, although of course they don't have the 
same coverage mandate).

* This is documentation of the values used *in UK federation metadata*, not 
necessarily the values used by the originating registrars.  We reserve the 
right to use different identifiers when we think it's appropriate, or to 
invent identifiers for registrars who haven't selected one themselves.

I have added a couple of paragraphs to the next draft hopefully making this 
clear.  I've also added a "futures" section indicating that we might use an 
external registry if one existed.

>       • [section 3.3] “particular care is given to consistency between the 
> different mechanisms.”
>               • Can you explain what you mean by this phrase? The values of 
> <mdui:DisplayName> and <md:OrganizationDisplayName> are independent of one 
> another in all respects.

We don't think that's the right approach, particularly in the case of IdPs, 
as it means that the "discovery name" of an IdP will be different on 
MDUI-aware discovery services such as our CDS, as compared to non-MDUI-aware 
discovery services such as non-Shib-EDS discovery services run by some major 
publishers.  We think that the same IdP having different "discovery names" 
depending on which SP you're using, so we see value in consistency between 
mdui:DisplayName and OrganizationDisplayName.

We don't (as far as I know) pay any attention to such correspondence in the 
case of SPs, and I don't think we have mechanical checks for consistency in 
either case, although perhaps I will look into that for IdPs.  It's tricky if 
multiple languages are involved, though.

>       • [section 3.3] How do we ensure the global uniqueness of 
> <mdui:DisplayName>?

Excellent question.  I think the bottom line is that you can't, and that we 
need to figure out how we are going to live with that.  I don't see it as 
being an immediate issue, but that just gives us some breathing space.

On the "living with it" front, I mentioned some possibilities in my mail to 
this list on 3-Apr, and I won't bulk this out by repeating that material here.

>       • [section 3.5.1] Thank you for only including entities with explicit 
> keys in the export aggregate. Note that:
>               • IdPs MUST have a signing key
>               • SPs SHOULD have an encryption key

We go further, and REQUIRE (SAML 2.0) SPs to have an encryption key, at least 
for now.  That constraint applies both to local and to imported metadata.

The current draft doesn't touch on our use of KeyDescriptor except in section 
2 where we describe how to use one.  I clearly need to add a 3.X section 
covering this.  I will try and do that for the next draft if I have time.

>       • [section 3.5.2] “UK federation metadata supports the inclusion of 
> <shibmd:Scope> elements in the metadata”
>               • Shouldn’t all IdPs be required to have a <shibmd:Scope> 
> element?

I think if you read the whole of that section, our position is clear: we 
require this of our members as a registration practice, but we don't reject 
imported metadata just because the originating registrar has a different 
practice.

My reasoning for this is that although an imported IdP with no Scope elements 
isn't going to be very useful to the majority of UKf SPs, it's not harmful to 
include one.  If an IdP chooses not to support scoped attributes, it may 
still have some value but spending time hassling people from other 
federations to declare a scope which they won't be able to use doesn't seem 
worthwhile.

>       • [section 3.5.2] FYI, InCommon does not support top-level 
> <shibmd:Scope> values in IdP metadata. In UKF metadata, is the positioning 
> of Scope elements mutually exclusive? (which is precisely why top-level 
> Scope elements are problematic in our view)

The Shibboleth implementation does not make the positioning of Scope elements 
mutually exclusive, and (as described in the draft) we always have the exact 
same list at both the entity level and at the role level.

I'm struggling to understand why you think this is a problem, to be honest.  
Even if I was to convince you that what we do isn't harmful (and I think that 
since we've been doing it since before Shib 2.0 was released that we have 
ample anecdotal evidence for that position) I wouldn't expect you to *rely* 
on any assertion about what we do to protect your federation against the 
perceived possibility of harm.  Instead, in your position and assuming that 
you see Entity-level scopes as problematic, I'd expect you to simply discard 
them from imported metadata.

Having said which, I think it's clear in retrospect that the whole "triple 
scope" thing was an error on my part brought on by irrational exuberance and 
zeal, and that we must consider consigning the Entity-level Scope construct 
to history.  That might mean that I'd start stripping it out of our export 
aggregate, and raise the issue of retiring it from our other aggregates at 
the next UKf TAG meeting.

Note that even if I decided that was the right approach, and removed 
EntityDescriptor-level scopes from the UKf export aggregate immediately 
(which may well happen) that shouldn't affect your behaviour at all.  If you 
think EntityDescriptor-level scopes are harmful, you shouldn't rely on our 
procedures in this area but enforce the constraints you think necessary 
yourself.  Remember that this is valid metadata, and that you need to plan 
for other sources than the UKf in the long run.

>       • [section 3.5.2] You allow regexp=”true” in UKF metadata, but don’t 
> allow regexp=”true” in imported metadata? Isn’t this a contradiction?

I don't see a contradiction.  We allow regexp="true" in those contexts where 
we trust the process to give the appropriate guarantees.  For now, that means 
that we trust our own processes in this area (because we're planning on 
generating regular expressions, not having them written by fallible humans) 
but we don't trust anyone else to do the same, even if they claim to.

If there was a way to verify that the language matched by a given regular 
expression had certain properties, I might feel more confident in permitting 
regexp="true" from selected partners.  That's a hard problem (if I recall, 
not even soluble in general), and one I see no benefit in pursuing given that 
hardly anyone other than the UKf has ever made use of the feature in anger.  
(In fact, the only people I've seen using it outside the UKf got it wrong)

> In any case, what is allowed in export aggregates?

In our export aggregate, we include metadata we have registered, from (at 
present) opted-in entities.

I don't see any reason for us to *not* publish regexp="true" scopes if we 
believe them to be correct.  In practice, as I've said, this is unlikely to 
happen in anything like the near future because we're only likely to see the 
benefits of regexp="true" for the aggregated schools sector IdPs.  The 
benefit there is in reduced maintenance of the *10,000* scopes in the sector 
(and potentially *30,000* if we reached the sector's potential) and of course 
in reduced metadata size: at present, those scopes are 27% of our production 
metadata file, more than 3MB.

In the other direction, if an entity exported from someone else has a 
regexp="true" scope in it, we drop it.  As there are effectively none of 
these outside the UKf, this turns out not to be an issue.  If there were some 
around that we actually cared about I'd degrade that to just dropping the 
regexp="true" scopes.

I'd recommend that, given that you have the same concerns about 
regexp="true", you take the same approach.  If you see a regexp="true" in 
inbound metadata, drop the entity or transform the errant scope away.  
Steven's pilot will be dropping those entities already, I believe, if he's 
using our standard block of checks.  As before with EntityDescriptor-level 
Scope elements, if you believe that this is a problem (and you should) then 
you would be unwise to rely on people simply *saying* that they won't send 
you regexp="true", but back it up by *enforcing* the constraint in code.  The 
advantage of this is that you no longer need to persuade people to give you 
that guarantee.

>       • [section 3.5.2] In InCommon metadata, a <shibmd:Scope> value MUST 
> be a registered domain, that is, a domain listed in the whois database. How 
> else do you ensure ownership?

There are two other mechanisms.  I definitely plan to document these in the 
FTS, but don't have time to get them into the upcoming edition so I'll give a 
brief summary here.

The second major mechanism is to require the member registering the entity 
but not owning the domain to persuade the owner of the domain to write us a 
letter giving them permission to use it for the entity registration.  In the 
case of an SP, this does not have to be a federation member; for an IdP 
(where scopes may come into play, with the increased risk that implies) it 
does.

The third mechanism is that of the "synthetic scopes" (like 
1234.567.eng.ukfederation.org.uk) which we as federation operator allocate to 
local authorities for use in the schools sector.  You can think of this as an 
extension of the second mechanism where we write ourselves a letter ;-)  
These are the ones we're investigating making use of regexp="true" for, 
incidentally.

>       • [section 3.8.1] UKF requirements around URNs may be more strict 
> than InCommon requirements. Our wiki page on Entity IDs has been rewritten 
> to clarify our policy.

Your policy as rewritten seems fine to me.  I don't think that in practice 
we're much stricter, as there are in my mind very few URN namespaces other 
than urn:mace which would ever qualify (urn:geant, *maybe*).

I took a quick look, but I can't see any current InCommon entities which fail 
to meet our nominally stricter criteria.  As we're agreed that the urn: 
scheme should be discouraged anyway, I don't see much value in relaxing our 
constraint either for the UKf registrar or for our import processes.  I'm 
probably being influenced by the need to mechanically check that entityID 
values are appropriate on import: I'm not going to just allow any urn: value 
backed up by an assumption that all our partners perform the same validation 
you would in this area; I'd rather take it case-by-case for each namespace as 
it comes up, with the assumption that in fact that will involve near zero 
work as everyone has already settled on http: and https:.

>       • [section 3.8.1] “URIs used for entityID values MUST contain a host 
> part whose value is a DNS domain.”
>               • What if the URI is a URL?

You clipped the first part of the sentence, which in full reads:

http-scheme and https-scheme URIs used for entityID values MUST contain a 
host part whose value is a DNS domain.

What's unclear?  A URI which was a URL would be either one or other of the 
above, so the constraint would apply.

>       • [section 3.8.1] “MUST be part of a properly delegated registry 
> under the urn:mace namespace, as described in [RFC3613].”
>               • That seems overly restrictive. Is the policy stated on our 
> Entity IDs wiki page acceptable?

Your policy is acceptable to me as one which would be "broadly similar" 
(actually, almost identical) to ours.  It would in theory permit some things 
which our mechanical checks would reject, but in practice that isn't the case 
for any existing entity and I'm fine with dealing with that when it comes up, 
if ever.

>       • [section 3.8.1] Your method of handling duplicate entityIDs is 
> quite reasonable.

Good :-)

>       • [section 3.9] There’s no need to repeat the definition of 
> <OrganizationName>, <OrganizationDisplayName>, and <OrganizationURL> from 
> the metadata specification.

It informs the subsequent discussion, I think.  I agree that it could be 
omitted, but as we've had it since 2006 I'm inclined to just let it stand.

>       • [section 3.9] “the <OrganizationDisplayName> contains a string 
> describing the function of the particular entity, and the <OrganizationURL> 
> contains a URL leading to more information as appropriate to the entity’s 
> function.”
>               • This seems to go beyond what is specified.

Yes, it goes beyond what the standard says.  That's really the point of 
section 3 in general, to go into more detail about our practices (and the 
standard is exceptionally vague in this area).

> The InCommon Federation certainly doesn’t use these elements in this way.

We don't require you to; I think the document is clear on that when it tells 
our consumers that for imported entities Organization (and implicitly its 
child elements) is "entirely determined by the originating registrar's 
registration practices".

>       • [section 3.9] “The <OrganizationDisplayName> should contain the 
> string by which the identity provider is to be known by discovery services.”
>               • If that’s the semantics in UKF metadata, fine, but that 
> interpretation is obsolete. Use <mdui:DisplayName> instead.

We RECOMMEND that people add MDUI metadata, and make use of it where 
available.  We don't REQUIRE that, and I don't think you do either.  So this 
*interpretation* (or perhaps "convention" would be a better word) is not 
obsolete in the case of:

* entities for which no MDUI metadata exists

* discovery services which are not MDUI-aware

Remember that this is primarily a document telling people what they can 
assume as guaranteed in their role as consumers, not what they should do as 
registrants.

>               • Our algorithm is very simple. For IdPs, use 
> <mdui:DisplayName> (if available), fall back on <OrganizationDisplayName> 
> (if necessary). For SPs, use <mdui:DisplayName> (if available), fall back 
> on entityID (if necessary).

We don't publish an explicit algorithm for interpretation of either MDUI or 
OrganizationDisplayName, other than referring to the MDUI standard.

> [section 3.9]  Are both <mdui:DisplayName> and <OrganizationDisplayName> 
> unique in export aggregates?

OrganizationDisplayName *will* be unique in our export aggregate, we check 
for that (although the check isn't language-aware so it's probably rather 
brittle).

I don't think we currently perform similar checks for mdui:DisplayName, but 
it seems desirable that we should.  I will look into it; this should 
certainly be documented one way or the other.

Having said which, as a relying party you should approach this cautiously in 
any case:

* even if I claimed it was true, anything that was going to cause downstream 
issues for you should be checked at your end as well

* even if the UKf gave that guarantee and you trusted that guarantee enough 
not to code defensively, it doesn't help you at all once you have even one 
other metadata source to deal with.

>       • [section 3.9] After all that, there is no discussion of 
> <OrganizationDisplayName> in export aggregates.

Any metadata in the export aggregate is just the same as in our other 
aggregates except where the document says otherwise.

>       • Section 3.11.2 is inconsistent with section 3.5.1.

I don't think so; 3.11.2 is in the "Future Directions" section and is 
additionally explicit that it is talking about the future and not the 
present.  Can you clarify the inconsistency you're seeing?

>       • [section 3.11.3] Please don’t use regexp=”true” in export 
> aggregates.

I've covered this above.  I am unwilling to give a guarantee that we will 
never do this, and you'd be very unwise to use any such guarantee (even from 
the UKf) as a reason to avoid coding defensively even if I did.

>       • AFAICT, there is nothing in this document about endpoint locations.


Well, there's a little in 7.3.1 and 7.4.1, but strictly speaking that applies 
only to SAML 2.0.  In fact, we require TLS on all endpoints today, both as a 
registration practice and an import constraint.

We do *not* constrain the host name part of endpoint locations in any way.

This does probably need to be documented.  Again, probably won't make it into 
this edition but there will always be a next edition under development.

Many thanks again for the comments.

        -- Ian

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