Dynamic Metadata and Artifacts

[Rod Widdowson]

> That somewhat explains why I've had difficulty following some of your
> messages but I'm still not totally clear why you're singling out the
> artifact flow. Exactly the same problem arises regardless of the
> flow...the SP needs metadata to validate the assertion, regardless of
> how it obtains the assertion (either by reference or by value). Why is
> this issue coming up at this late date? (Sorry, I'm afraid I still
> don't get it.)

It's complicated, and I think that you and I are worrying about completely different things....

It is a matter of faith in this whole monstrosity that a software package in possession of the metadata for an entity will be able to drive the artifact identifier.  Let's call this an oracle.  Without an oracle we are all dead in the water.  I have a feeling that it is this oracle thing that is worrying you.  For me it is a given.

Anyway, this means that the Batch Metadata Providers (Folder, XML) can (and do) use this oracle (embedded in its code) to calculate up front what artifacts IDs it might want to respond to.  Since metadata is loaded before any lookup the Batch providers are covered.

This also means that the Dynamic Metadata providers can (and will) use this oracle (embedded in its code) to cache the mapping of artifact ID to metadata but they have to have seen the entityID first and done a resolve on (so as to give them metadata which they can pass through the oracle).  So all the dynamic metadata providers are OK in the case when the SP first sees the entityID and then (within the lifetime of the metadata) an artifact.

But this falls down in the case when the metadata goes out of validity, or when the first time that the SP ever hears from this IdP is with an artifact.  So this is the case (in general) that concerns me.

Now let's go down another level.

We are proposing 4 different flavors of Dynamic Metadata Provider

1) MDQ:	<MetadataProvider type="MDQ" baseUrl="http://mdq.example.org/global/" />
2) Local:	<MetadataProvider type="LocalDynamic" sourceDirectory="localDynamicDir" />
3) WellKnown:	<MetadataProvider type="Dynamic" />
4) Substitute:	<MetadataProvider type="Dynamic> <Subst hashed="SHA1">http://mdq.example.org/global/entities/$entityID</Subst> </MetadataProvider>
	and:	<MetadataProvider type="Dynamic> <Regex match="YouHadOneProblem">http:/Now.You.Have.2.com/$1</Regex> </MetadataProvider>
	
So taking each in turn in the "artifact but not preceding entityID" case

1) In the MDQ case we can assume that the Server is equipped with the metadata and an oracle and we use the {sha1} thing
2) In the Local case we can assume that the populating software (which is not the SP) is equipped with the metadata and an oracle and will populate the directory appropriately

But in the other two cases we are completely short of luck. We have no entityID and we have nowhere to plug the artifact and because we have no metadata we have no oracle.

So my question was "In the case when someone configures a WellKnown or Substsitute dynamic metadata provider *and* we see artefacts should we warn that this may not always work.

Rod