Shibboleth Developers

["Scott Cantor" <>]

> I will test it and report any fixes needed. For example, a quick look
> notes that you try to cast the Node passed to Initialize to a 
> Element, but the configuration file passes an Element for Inline XML
> and a Document for XML read in when a URL is provided to an external file.

Right, forgot a Node can be a Document. Mostly I was just hoping it was a
parsed tree, and not the enclosing element with the uri attribute.

> the partner Role. If not, there is code to extract a partner Entity from
> the SAMLObject being validated and look up the Entity through a Metadata
> interface argument. However, if the Keys are based in the Role, I don't
> think the Metadata lookup fallback is going to work any more. I suggest
> dropping that argument and require that the RoleDescriptor be 
> non-null.

Seems like I had some reason for doing it that way, but I can't recall, and
looking now I don't see any place where the role wouldn't be known. I
suspect it predates some of my understanding and maybe was me trying to be
as general as possible. It would only work now if indirect trust via a CA
was being used anyway, so I think you're right.

We need to work out a new API with Walter anyway, so it's time to revisit
it.

> This works if you can chain up to the Key Extension data "internally" from
> the Role to the Entity to the Entities without having to come in from the
> outside with a new "lookup" call.  

You can. I changed the interfaces to capture the entire tree and added
getEntityDescriptor/getEntitiesDescriptor accessors to walk up the tree. The
old getGroups() logic is replaced by recursive backstepping (most specific
to least specific).

I'll divert to a couple of small things and then put a schema proposal
together for the trust extension.

-- Scott