RE: [security-services] Comments on SAML 2.0 Core draft-19...

["Conor P. Cahill" <concahill@aol.com>]

Scott Cantor wrote on 8/9/2004, 12:06 AM:

 > Some quick reactions...

And some less quick reactions...

 > > * Lines 722-731: These make statements as to the validity
 > > of the assertion based upon the conditions.  I think that it
 > > should refer to the condition check step in the validation
 > > process rather than saying that the assertion is valid.
 >
 > I'm not sure there's a difference. An assertion *is* valid if its
 > conditions
 > are valid. It may not be acceptable for some use or some profile, but
 > that
 > doesn't make it invalid in terms of core. Maybe I'm missing an edge case,
 > but that's how it seems to me.

First off, unless they are formatted incorrectly, I would say that
the condistions are always *valid* (as in a correct condition).  The
issue is that the valid condition is not *met*.

I consider the validity check to involve multiple steps including:

    a) Basic Schema validation
    b) conditions are met
    c) Signature validation

All in all, I don't think this is a biggie.


 > > * Line 1873: Strongly recommend that IsPassive default to
 > > "false" not True.   The passive request is the exception to
 > > the rule and the default should be set accordingly.
 >
 > +1, I copied this from ID-FF, but I was a little confused by it myself. I
 > didn't think true was the more common case, but I thought maybe this had
 > been concluded otherwise in Liberty discussions.

If it was that way in ID-FF that was a mistake that I missed in my
review of the ID-FF specs.  I can say that there was no significant
discussion in Liberty where this was consciously decided as my goal
there was always to make sure that the normal case had the least
amount of verbosity.

 > > * Lines 1942-1946: I thing this is a bit watered down
 > > from what it should be.
 >
 > I watered it down on purpose. It says to me nothing more than "you can
 > create a new identifier". There's no implication beyond that that I
 > can see.

The problem is that for many of us it isn't "you can create a new
identifier" but rather a positive statment of "I want you to create a
new identifier".  The difference is subtle but signficant.  We want
the SP to clearly indicate that they are initiating a new identifier
creation as opposed to having it look like the default is to do so.

So, I would rather see the attribute called "PleaseCreate" or
"CreateNew" with the default to being "false".  While technically
there isn't a big difference in the specs, this will have impacts
in privacy group discussions.

 > > Essentially this is specifying
 > > that the Requesting Entity is asking the Identity Provider to
 > > establish a new relationship identifier (federation
 > > identifier) for the subject at the relying party.
 >
 > The identifier may well be global and not specific to the relying
 > party. It
 > definitely could be "federated" in the sense that you mean it, but that's
 > not a requirement, so the text doesn't say that.

In the case where the Identifier already exists (i.e. it is a global
identifier) the IdP would not need to create a new one.

 > > * Lines 2064-2066: This makes me think that the relying
 > > party and the request issuer must be the same entity.    I
 > > would think that only the Relying party MUST be included.
 >
 > The intro sentence to the bullets says that the rules here are
 > specific to
 > the case that there are no other relying parties specified (meaning no
 > Conditions element in the request). So there's no basis to determine a
 > relying party other than the request issuer (the simple/common case).
 >
 > > * Lines 2242-2263: Suggest making "terminate" an optional
 > > boolean attribute and not an element.  If we're gonna keep it
 > > as an element, we need to define the type (right now on line
 > > 2263 it's an empty complex type).
 >
 > I preferred it as an element, because it's so central to the action being
 > requested, and because it's easier than wasting time with it as a boolean
 > when it makes no sense for it to be false. As far as the schema,
 > people sort
 > of need to make up their mind. ;-)

 From the looks of the rest of the schema, we did not make something
an attribute or an element based upon the centrality of it to the
action taking place.  And I don't think it should be.  Attributes
aren't a second class component in XML.

It makes a whole lot of sense for it to be false if the call is
changing the ID vs deleting the ID.

 > Thanks (though it's going to be tough to do all this in a week),

Sorry.  No good excuse other than I just didn't get around to it.

Conor