SAML metadata algorithm support extension questions
Brent Putman
putmanb at georgetown.edu
Fri Mar 21 18:57:14 EDT 2014
Mostly for Scott or maybe Ian:
Question 1:
In the spec (section 2.5 Metadata Consumers) it says:
> With respect to use of XML Signature, the presence of any
> <alg:DigestMethod> and <alg:SigningMethod> elements at the level of a
> role element MUST take precedence over any such elements at the level
> of of an <md:EntityDescriptor> element, and the two sets are not
> combined if both are present.
I'm having trouble parsing this sentence (entirely possibly b/c it's
Friday... ). I see at least two possible meanings:
1) The presence of EITHER a SigningMethod OR a DigestMethod at the
RoleDescriptor level means you ONLY consider the RoleDescriptor level
for *both* elements.
2) SigningMethod and DigestMethod are considered separately, e.g. the
presence of a SigningMethod on the RoleDescriptor does not preclude
using the DigestMethod on the EntityDescriptor IF the RoleDescriptor has
no DigestMethods. And vice versa.
I guess the "... over any such elements ..." part is unclear to me,
whether the "such" refers to the 2 elements together as a set, or
separately.
(It's clear that in either case you don't combine same-named elements
from both RoleDescriptor and EntityDescriptor.)
Opinions? If it's not just me, maybe a question for saml-dev, or a
potential errata to clarify.
I've currently implemented it as #1, but easy enough to change.
Question 2:
A resolver processing edge case: For both signing and encryption, if
there are algorithms present in metadata but the local
whitelist/blacklist policy winds up filtering them all out: Are we then
free to choose from the local list of preferred algorithms (which
basically means falling back to the non-SAML-aware resolver superclass
logic)? Or do we just fail to resolve? Off-hand I'd think we do the
former and at least resolve something usable, but wanted to get feedback
first.
--Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140321/555a8ef2/attachment.html
More information about the dev
mailing list