I have applied most of the corrections proposed by Prateek, the folowing
appear to be somewhat beyond a typo fix however:
> (2)
>
>
> 996, use of ConfirmationMethod
> 656, use of AuthenticationMethod
>
> There is some inconsistency here. My understanding
> in earlier versions was that the filter was built around
> AuthenticationMethod (otherwise why should it be
> specific to <AuthenticationQuery>?). My guess is
> that line 996 should read:
>
> <AuthenticationMethod>[Optional]
I have not problem with this change but it is more than correcting a typo so
I thought I would bounce it to the list.
> 393:
>
> I am puzzled by the maxOccurs="unbounded" attribute for
> <ds:Signature>.
> I would have thought this to have cardinality 0 or 1 (no need
> for maxOccurs
> attribute). A close examination of Section 5.1 (1311)
> does not yield any justification for such a cardinality.
Again, no problem with me but more than a minor editorial change.
> add to line 1298:
>
> The message integrity of assertions must also be guaranteed by use of
> appropriate technology.
>
> add to line 1304:
>
> The message integrity of requests and responses must also be
> guaranteed by
> use of appropriate technology.
I could not get these two comments in registration with my text, please
supply more context.
> (9) replace line 1348 by:
>
> SAML processors MUST use enveloped signatures for signing
> assertions and
> protocols. SAML processors SHOULD use RSA signing for public
> key signatures.
Here I reworded slightly since SHOULD use is somewhat strong, should support
is closer... isn't verification a MUST though?
SAML assertions and protocols MUST use the enveloped signatures for signing
assertions and protocols. SAML processors should support use of RSA signing
and verification for public key operations.