MD Extensions for Registration and Publication Information

[Chad La Joie <lajoie@itumi.biz>]

Before Christmas I uploaded working draft 2 of the "SAML V2.0 Metadata 
Extensions for Registration and Publication Information Version 1.0".  I 
gave a 5 minute description of this document on the last teleconf but I 
figured I'd recap here so it was on the list.

The extensions given in this document come from the wacky world of 
research and education federations.  Such federations tend to have a 
central registration authority and the <RegistrationInfo> extension is 
meant to capture some data pertaining to the registration process (e.g. 
who did it, when, and how).

Most of the software in the aforementioned federations discover 
necessary information about would-be partners by downloading metadata 
documents from a trusted, external source.  They then cache the 
information for a while as, in some cases, the documents can be quite 
large and expensive to process.
The <PublicationInfo> is meant to provide information about a particular 
publication of metadata (e.g., who published it, when, and what is the 
publisher's identifier for the document).

Lastly, in recent years there has been talk about "interfederation" 
which, from a technical perspective, just means passing around metadata 
across traditional federation boundaries.  As an example of why you 
might want to do this; assume you were a scientific journal publisher, 
joining and maintaining a relationship with 40 different federations is 
a pain but joining one that provides your metadata to the other 39 is 
much nicer.  To track the "flow" of metadata from one publisher to the 
next we have the <PublicationPath> extension which allows some one to 
see "This bit of metadata originated with A and traversed B and C before 
it got to me".

Now, I'll note that I have tried to keep the overall number of items 
tracked to a minimum for the present.  I've already passed this 
document, in previous forms, to various federations operators and some 
came back with a long list of things they'd like to track.  When I asked 
"Is this information really necessary for the *consumer* of metadata?" 
nearly everything fell away.  I do not want the metadata document acting 
as a database of internal process/state information for registrars and 
publishers.

P.S. I'll note that one individual already found a mistake on line 164 
where I referenced <CreationInstant> and <SerialNumber> elements which 
should in fact be the attributes creationInstant and publicationId, 
respectively.  I've got the mistake fixed in my copy and it'll show up 
in WD03.
-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered