Interfederation

[Ian Young <>]

On 27 Feb 2013, at 13:26, Tom Scavo 
<>
 wrote:

> I'm guessing that this subcommittee will recommend full support for MDRPI.

I guess that would depend on what you meant by "full" and "support" ;-)

There is an awful lot of expressive power in MDRPI, but there are really only 
a couple of things in it that carry most of the value.  The good news is that 
those few things are really very simple to implement.  Let me just document 
what we've done in the UK federation to give people a general feel for what I 
mean.

Every aggregate we publish has a top level <Extensions> containing something 
like this:

<mdrpi:PublicationInfo creationInstant="2013-02-26T18:08:41Z" 
publisher="http://ukfederation.org.uk"/>

This has some diagnostic value, but I can't think of any mechanical use cases 
for it.

The important one is that every entity in every aggregate we publish has an 
entity-level <Extensions> containing something like this:

<mdrpi:RegistrationInfo registrationAuthority="http://ukfederation.org.uk"/>

The registrationAuthority value depends, of course, on where we got the 
entity from.  Entities sourced from our friends in Ireland, for example, end 
up with one of these:

<mdrpi:RegistrationInfo registrationAuthority="http://edugate.heanet.ie"/>

Likewise the channel definition I've written for importing InCommon metadata 
ends up putting this value in, after consultation with Tom:

<mdrpi:RegistrationInfo registrationAuthority="https://incommon.org"/>

The important thing is that any consumer of any of the metadata we publish 
can tell who registered each entity, which gives them a handle to which they 
can think about applying policy.  We do the work required to ensure that 
value is accurate: for example, the process for handling a federation partner 
is to establish the expected value for registrationAuthority, *default* to 
that if no <RegistrationInfo> is present, and then *check* that any 
<RegistrationInfo> now present contains the expected value.  So, for example, 
if Edugate start putting <RegistrationInfo> into their entity metadata, the 
defaulting won't take place and we'll pass on any additional details they 
provide; but that doesn't mean that they can pass through a claim that an 
entity was actually registered by InCommon (we'd drop that entity entirely 
from that channel).

As I said at the top, there's a lot more that you *can* say with MDRPI, it 
just turns out not to be very useful for mechanical.  You can put in a link 
to your registration practices, but until we can get the ethical concerns 
around wiring up a lawyer's brain directly to our metadata aggregator 
resolved (feel free to enter a JIRA ticket) it's pretty unlikely that we'd 
use that for anything at the federation level.  I'd want to know you 
performed a decent level of due diligence on entity owners before registering 
anything I saw, but that's a separate issue; I simply won't do business with 
anyone who can't pass that test.

At present, the only thing other than registrationAuthority that we actually 
add to <RegistrationInfo> (and only in cases where we know it) is the 
optional attribute giving registration date and time:

        <mdrpi:RegistrationInfo 
registrationAuthority="http://ukfederation.org.uk";
            registrationInstant="2012-03-27T15:54:52Z"/>

I can't see a real use case for processing that information, though, so we 
haven't gone to the effort required to backfill it, and it's only available 
for more recently registered entities.

Bottom line: support for MDRPI at the minimum level described above is 
extremely valuable for any aggregator, and it turns out to be really easy to 
do at the registrar level, as it's just a fixed string.  An aggregator can 
compensate if that's not present, however, so it's not essential that it be 
done at that level until you're building your own aggregates from multiple 
sources.  I would strongly recommend that any aggregate which does contain 
entities registered by multiple registrars always includes basic 
RegistrationInfo for every entity.

        -- Ian

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