RE: [security-services] SAML metadata lifecycle issues

["Scott Cantor" <cantor.2@osu.edu>]

I'm quite interested in this topic, so in the interest of providing an
alternate perspective from another implementer....

I believe that the PKI componentry is neither necessary nor sufficient (nor
desirable if you want to get to the heart of it), so I prefer to look at
both the reactive and proactive scenarios presented in the write up as
potentially metadata distribution and exchange problems rather than PKI
problems.

We've aggressively pursued a strategy to make the PKI irrelevant, and we go
so far as to ignore certificate content when they appear in the metadata. If
you think about what it means to put a bare key in there (which is perfectly
legal and should be supported by products), that should explain why.

It should be understood that multiple keys are a possibility and
implementers absolutely need to be supporting that, so if we need to state
that someplace, we should. The schema was intentionally written that way
(and that was true in ID-FF I think). Efficiency is a function of how well
keys are identified in messages, and that's really nothing new, since
KeyInfo is badly in need of profiling anyway.

So I guess you'd say I have the diametrically opposite view of the role of
the metadata (whether it's SAML's schema or somebody else's), and we'd like
to see vastly improved support there from products rather than the loose and
unworkable import/export approach taken today.
 
To stimulate controversy:

https://spaces.internet2.edu/display/SHIB/TrustEngine

-- Scott