Shibboleth Developers

["Scott Cantor" <>]

> Where did this <shib:Domain> element come from?  It's not mentioned in
> the protocol spec...

I forgot to add it to the last draft.

> Possible locations:
> "<providerId>/SSO/POST"
> "<providerId>/SSO/Artifact"

Doesn't work, see previous note. I should say, it works fine for Java, but
this isn't just for Java.

> - Shouldn't there be two <md:EntityDescriptor> elements, one for the
> IdP and one for the SP?

If the names are different, yeah.

> - Will each individual <md:EntityDescriptor> element be signed?

I hope not...I'm not even sure signing anything matters here. This is not a
research project federation, it's an "anybody can join and there's no
security" federation. Much like InQueue except the first part.

> - Why doesn't the <md:KeyDescriptor> element in the
> <md:SPSSODescriptor> element have a use="signing" attribute?

I don't think a TLS credential qualifies as either signing or encryption. Or
maybe it's both. My code treats "omitted" and "signing" as equivalently
valid for use with TLS, whereas actual signing would look only at the
"signing" keys. I suspect that's errata, unless Liberty (where it was copied
from) had some kind of convention for it.

But since actually *using* a KeyDescriptor for trust checking is
fundamentally non-interoperable anyway, I don't think it matters. There's no
way different products will work together unless they all document how keys
are to be expressed and used, and my guess is metadata may vary as input to
a product based on how it does this.

-- Scott