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

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

Thanks, comments inline.

> [lines 186--188] Granted, section 3.4 of [SAML2Core] says that "A SAML
> authority that supports this protocol is also termed an identity
> provider" but that doesn't preclude an IdP from supporting other
> protocols, does it?

Well, yes, I think it does in the strict sense. I don't see a problem
getting around it, but I feel the need to just acknowledge it.

> Where does it say that an IdP is an "entity that
> issues authentication assertions"?

Formally, an IdP in SAML supports section 3.4, and that protocol is about
authentication assertions. One follows the other.

> I think that definition is too
> restrictive.  The definition I often give (correct or not) is that an
> IdP is a producer of assertions.  You can fiddle with words a little
> bit, but I think that's the correct level of generality.

Correct or not, I don't think this is the place to change it. If we want to
clean up the definition, we can use errata for that, I suppose, and then I'm
happy to change the text.
 
> [lines 212--217] This requirement seems to be more trouble than it's
> worth.  Why not just map each and every such claim to a
> <saml:Attribute> element?

Hmm. Why not do it? NameIDs have special support in SAML in other protocols
and you lose that if you use attributes. It's not like this approach is
complicated, quite the opposite.

> [lines 241--242] If an Address XML attribute is included, what does
> the RP need to do about it, if anything?  More generally, what does
> the RP need to do to confirm the subject?  (This is a glaring
> omission, I think.)

This section is about IdPs and issuing the assertions, not consuming them,
so I think it's better to "address" that in the opposite section in 2.4.5.

> [lines 243--247] The normative language regarding the Recipient XML
> attribute amounts to a meaningless requirement.  On the one hand, it's
> a MUST (that depends on a condition no less), but then in the next
> sentence it's a SHOULD NOT.  This paragraph needs to be cleaned up, I
> think.

I'm open to suggestions, but the IdP cannot always do certain things. All
I'm trying to say is that if you know it, you MUST include it. I can't
require it, because it's not always known, but carrying it is a significant
protection that I'd prefer not to just lose.

Is it clearer just to cut the last sentence? Seems like it reads ok without
that.

> [lines 254--256] This is a meaningless requirement since the MUST
> depends on a condition.  I suggest you remove the condition and
> reformulate the requirement.

Well, I don't think it's meaningless...it's a direct instruction to the IdP
that if the condition is met, it MUST do something. I don't think it's
clearer to say "you MUST do X if Y", but if others prefer that formulation I
can turn it around.

I'm the first to say that the underlying specs are extremely messy in this
area, but that's the basis I have to work from. You don't always know the
RP, and even worse, you may know a location and nothing else. My perspective
was that it was simpler to formulate requirements in terms of whether the
information was available, and not try to combine the Recipient and
Condition rules.

> [lines 262--265] This paragraph is confusing since the SHOULD and the
> MUST seem to contradict each other.  The condition on the SHOULD
> doesn't help, either.

It doesn't read well to me either, I'll see if I can reword it.

> [lines 298--299] I don't believe [SAML2Prof] has anything to say about
> confirmation of subjects, so I believe you need to spell this out.

I think core and profiles say an awful lot, but IIRC I had the same view
about the original SSO profile, so I'll add some text consistent with that
profile to this section (i.e. I lost the argument then too).

> [lines 306--307] I don't understand this sentence.  I guess I don't
> know what "in the manner described by [ISIP]" means.  Is this really a
> requirement about the use of SAML metadata or is it something else?

It's a requirement to take the loose approach in ISIP and tighten it up.
ISIP doesn't have consistent nomenclature or "modeling" of entities that
allows me to reference something concrete. It has some loose language about
logical naming, and that's about it. I'll see if I can add some text and a
section reference that points to something more explicit.

> Suggested edits:

Applied all these.

Thx,
-- Scott