Subject: Re: [security-services] comments re draft-sstc-saml2-infocard-01
Good to see this close reading of the doc! My reactions to this comment thread below (yes, I'm cheating, not having given it quite the close reading Tom has :-). By the way, I've completed AI #0338 ("Circulate Infocard Profile for review"). On Aug 4, 2008, at 5:53 PM, Scott Cantor wrote: > 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. I think the language is okay. The SAML spec as a whole does indeed define "identity provider" as a term of art for its own purposes, and the mention in this profile is a pretty elegant way to introduce the "community's" use of the term generally. > > >> 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. Scott's right; IdP in official SAML-speak is a specialization of a SAML authority that does this particular job. But I don't think we need to get hung up on this too much. > >> [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. I do think we need to take advantage of the optimization that SAML provides with NameID 'cause that's what is generally supported... > >> [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. No comment. > >> [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. 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. > >> [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. This is similar to the case just above. The condition depends on extra-protocol knowledge, which is untestable. I generally hate to use SHOULDs when it's possible to use MUSTs, but I think MUSTs in these two cases would be a bit misleading. > 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. FWIW, how about "If a suitable key belonging to the relying party is known, the identity provider SHOULD encrypt the resulting assertion in accordance with section 6 of [SAML2Core] and return the result to the requester in the form of a <saml:EncryptedAssertion> element." (Can we say what bad things will happen if you don't follow the SHOULD recommendation, or give guidance in a note on when to encrypt/not encrypt?) >> [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). No comment. >> [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. This is an interesting topic that we can perhaps explore further if we take a closer look at the new WS-Fed metadata proposal... Eve Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc.