Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] MDRPI

Subject: Interfederation

List archive

Re: [inc-interfed] MDRPI

Chronological Thread 
  • From: Ian Young <>
  • To:
  • Subject: Re: [inc-interfed] MDRPI
  • Date: Wed, 27 Feb 2013 17:32:37 +0000
  • Authentication-results:; dkim=pass (signature verified [TEST])

On 27 Feb 2013, at 13:26, Tom Scavo

> 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

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

<mdrpi:PublicationInfo creationInstant="2013-02-26T18:08:41Z"

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=""/>

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=""/>

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

<mdrpi:RegistrationInfo registrationAuthority=""/>

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:


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

Archive powered by MHonArc 2.6.16.

Top of Page