RE: [security-services] comments re draft-sstc-saml2-infocard-01

["Scott Cantor" <cantor.2@osu.edu>]

> I do think we need to take advantage of the optimization that SAML
> provides with NameID 'cause that's what is generally supported...

I guess my primary concern is that NameID management (and I suppose mapping,
but mainly management) continues to be composable. I have other reasons, but
that's the most concrete one.

> I'm more troubled by the MUST, which is untestable because it depends
> on extra-protocol knowledge residing with the endpoint in question.
> Sounds to me like this should be STRONGLY RECOMMENDED or something,
> with an indication of the occasions when it shouldn't be done.
> Deployment/interop profiles could, for their purposes, tweak it into a
> MUST and do conformance testing based on that assumption.

With respect to the Recipient and Audience issues, I'm reconsidering my
thoughts about this. Rather than try to codify a distinction at this layer
between location and identity (something we got wrong in Shibboleth in the
early versions, so I'm well versed in this mistake), I think we want to
solve this by getting rid of the extra-protocol aspect.

I suggest we drop Recipient, and require the Audience condition if the RST
includes the AppliesTo element, and be done with it. That's in-band, and is
testable. Audience may be "de facto" used to refer to identity these days,
but SAML leaves it open. I suggest we just put the string in there and leave
it to the RP to determine whether what shows up is "acceptable".

In practice, that just means you run your condition validator with both your
entityID and the processing endpoint in the local audience set, and there's
no harm done.

Once we codified Audience during SSO, Recipient became redundant, and is
mainly there for historical reasons. Dropping it here is cleaner and doesn't
significantly alter any risk.

-- Scott