RE: [imi] SAML 2 profile questions

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

Mike Jones wrote on 2009-10-14:
> There are a number of places where the draft says "SIP", and what I think
is
> meant is "IMI 1.0".  In fact, I haven't found one instance where the draft
> is actually referring to the Simple Identity Provider (SIP) profile (for
> self-issued cards).  These references should be updated.

This is an OpenOffice bug, I mentioned it on one of the calls. The original
draft was referencing SIP as the name of the pre-OASIS profile (not the
self-issued thing specifically) and I changed it but it's not "holding" when
I generate the PDF. I'm working on it for the next draft.

> In 2.3.3, why  is the AuthnStatement mandatory, rather than optional? 
> Isn't it legitimate to have the token convey claims while being silent
> about authentication?

The profile mandates authentication from the selector to the IP/STS, and the
existing SAML profiles in the world for SSO all mandate an AuthnStatement,
and the primary focus of this profile is to be consistent with that
practice.

> Similarly, why is the AttributeStatement optional?  Because sometimes
there
> are no claims?

Yes. Subject is outside of the statement level in SAML 2.0, so an assertion
of just an identifier can be devoid of attributes.

> Does this mean that there would be a claim whose value does not come from
a
> saml:AttributeValue element of a saml:AttributeStatement, but instead,
whose
> value comes from the saml:NameID value of the saml:Subject?  Could you
give
> an example so we have a better idea what this would look like and what the
> goal is here?

The goal is again to support common practice and to permit well-known
identifier types familiar to SAML deployments to be used within IMI. Some
implementations (mine notably not included) do not handle a free interchange
between NameID and Attribute syntax, so things that are defined to be a
NameID sometimes have to be there or cause breakage. It's not a particularly
attractive property, but it's a common one.
 
I can insert an example.

> In 2.3.3, the draft states that "the assertion MUST be signed".  I
> understand the value of this, but I'd like us to at least discuss this
> before assuming that this should be a MUST.  For instance, is this a MUST
> when the token is used with the SAML 2.0 protocol?

It is if you don't sign at the protocol level, and here the protocol is
between the selector and the RP, so the IdP can't sign at the outer layer.

> 2.3.4 states that "The <saml:SubjectConfirmationData> element, if
> present, MUST NOT contain a NotBefore or Recipient XML attribute."  Why
> is that the case?

The NotBefore restriction is copied from the SAML 2.0 SSO profile for use of
bearer tokens and is just a way of avoiding spurious problems because
there's no use case involving the attribute.

The Recipient restriction is to avoid the need to special-case non-auditing
cards and to deal with the fact that in the general case, IMI doesn't assume
that the IdP has in hand the *location* of the RP endpoint (which is what
Recipient is populated with).

This relates to the token scope issue. There's a single field in the
protocol that is being used to carry both identity and location, which are
fundamentally different things. Moreover, you can't tell which is which
within a given token scope. So to avoid having to make the distinction, I
simplified the profile and just left Recipient out in favor of using
Audience as the scope restricter. From a security PoV in SAML, they're
actually redundant; it's a historical thing I won't bother going into.

Essentially, I'm trying to keep Recipient "clean" of misuse, knowing that
Audience historically is much more loosely interpreted anyway.

> In 2.4.1, why is the token type not urn:oasis:names:tc:SAML:2.0:assertion
as
> per the IMI 1.0 spec example, rather than http://docs.oasisopen.
> org/imi/ns/token/saml2/200908, which seems like an unnecessary
introduction
> of a new identifier?

It started out as what you're suggesting. I changed it when I submitted the
draft here because the IMI TC doesn't have standing to define the meaning of
that URN (that goes for the 1.1 URN too, but I've already registered my
objections over that). I also felt it was best to avoid claiming a fairly
"canonical" URN for a profile that might not be the only/last word on SAML
2.0 usage.

> 2.4.3 states "If it does include a <wsp:AppliesTo> element, it SHOULD NOT
> identify itself using the location of its endpoint, as this complicates
the
> identity provider's ability to identify the relying party. A logical name
> SHOULD be used instead."  Given that existing practice is typically to use
> an endpoint, shouldn't this be softened to admit the use of either logical
> identifiers or endpoint addresses?

I didn't see a strong reason to, given that using locations is a limited
practice in light of the fact that wsp:AppliesTo only shows up today in
RP/STS deployments, since WS-SP can't be expressed by a RP site alone. It's
also an arbitrary choice what to put there, so it doesn't seem onerous to
start encouraging good practice in identifying RPs. It's also a SHOULD after
all, not a MUST.
 
> 2.4.4 Again refers to the NameID element in the context of language
talking
> about claims.  Is it the intent of the spec that a special case be made
for
> NameID to treat it as a means of representing a claim, even though it is
not
> a SAML 2.0 attribute?

Yes. That's just the reversed companion of the earlier text.

> Do others
> feel that this criticism of non-auditing cards, which have important
privacy
> properties, is a bit over the top?

For the record, that was the result of the reaction of our developers to the
potential of being asked to implement this.

Thanks for the detailed review.

-- Scott