Shibboleth Developers

["Scott Cantor" <>]

> Well, the spec can't guarantee attribute statements only, I understand
> that, so this begs the question of what to do if some other statement
> type appears in the response.  I suppose the easiest thing to do is
> ignore any non-attribute statements and log a warning, but I'd feel
> better if the spec had something to say about this (however brief).

I don't see any need to do anything, as an implementer, but if you want it
to warn somebody, that's fine. The spec as it stands in this respect is
correct, but you can make a note that this should be clarified.

I'll add a product for the specs to bugzilla, that way we can track errata.

> Similarly, according to the spec, the IdP SHOULD include a Audience
> condition in the response, but what if there is no Audience condition?
>  Should the SP simply log a warning and be on its way?

If you include a condition, then the SAML specification is clear on what you
should do (but you never have to as a relying party), so in that respect
it's fine. If you don't include one, then the processing rules are still
entirely clear because there is nothing special to do at all as a relying
party. A warning doesn't really make sense to me. The SHOULD is there as a
warning that unless you have a reason for not restricting the audience, you
should do that much.

I think it's not very similar to the other case, basically.

> Oh, so there are a bunch of additional requirements here:

No, there's pretty much two. The rest are just covered by SAML, but don't
amount to things that most implementers pay close attention to within a
given profile because the security of the system usually derives from other
assumptions.

> - The query SHOULD NOT have a SubjectConfirmation element.  (Does the
> IdP just ignore one if it happens to be included?)

No, because it has to go into the assertions. I actually think the AA checks
this now, but I could be wrong.

> - Each attribute statement SHOULD NOT have a SubjectConfirmation
> element.  (Again, simply ignore it if there happens to be one?)

Not if you want to be strictly correct, but ultimately you're the relying
party, you can pretty much do whatever you like. SubjectConfirmations don't
make all that much sense in back-channel queries for non-forwarded
assertions like this, they're closer to "undefined" than strictly adhered
to.

> - The Subject of each statement should "strongly match" (using
> language from the SAML 1.1 spec) the Subject of the query.

Right, this is a given.

> I presume any statement with a Subject that does not strongly match
> the Subject of the query should be discarded?

Pretty much, if you want to be rigorous. Guess how many commercial
implementations of SAML will notice?

-- Scott