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