Tom, thank you for providing these comments. I assume you're
referring to draft-10-diff.pdf.
On 7/7/06, Thomas Wisniewski <> wrote:
>
> 1. line 183: s/value of/value is/
I can't verify this typo. Is this from a different version of the document?
Oh, I see what you're saying. You're using the 's' notation
differently than what is typically done. A kind of "reverse polish
regex operator," huh? :-)
It's not a big deal, but I think "value is" is the correct wording in this case.
> 2. line 249: s/5.2.2/4.2.2/
My fault, this is merely an artifact of the diff. If you check
draft-10.pdf (no diffs) you'll see that the ref is correct. (Sorry, I
haven't yet figured out how to effectively use OpenOffice.)
> 3. lines 379-381 and 423-425 -- I suggest that you remove these lines. When
> using metadata, the use="encryption" attribute is typically used for
> including a public key or X509 certificate (for example) that is used by the
> metadata user to encrypt a symmetric key. The symmetric key is *not* a
> previously established key. Actually if you did have a previously
> established key, you would not need to encrypt it (as it would not be sent
> over the wire).
You're right of course. Thanks for pointing this out. Would the
following re-wording suffice?
[lines 379--381] To permit service providers to encrypt symmetric keys
in accordance with this profile (section 4.2.2), there SHOULD be at
least one <md:KeyDescriptor> element with attribute use="encryption"
in identity provider metadata.
[lines 423--425] To permit identity providers to encrypt symmetric
keys in accordance with this profile (section 4.3.2), there SHOULD be
at least one <md:KeyDescriptor> element with attribute
use="encryption" in service provider metadata.
> 4. lines 392 and 439 (in relation to the above stmts) s/encrypt symmetric
> keys/encrypt previously established symmetric keys/
Agreed.
> 5. line 481-486 Add the following thought somehow. Basically,
> transport-level security alone will not provide SAML message authentication
> of the sending party. I.e., a receiver can authenticate any requesting party
> it trusts and that will provide confidentiality and message integrity.
> However, it does not satisfy the requirement that the message (SAML xml
> content) sent is in fact coming from the authenticated requester. For
> example if the receiver trusts requester A and requester B. What if
> requester A sends a SAML message stating that its IssuerName is that of
> requester B. Strictly tranport-level security would not suffice. So either
> XML signatures is required or SAML message authentication is required.
> So for Enhanced Mode, transport level security would not suffice in
> single-hop scenarios (the current text implies it would be ok -- and the
> need for dig signatures is really because of the possibilitly of multi-hop
> scenarios).
This is an important comment. I need to think about it.
Thanks,
Tom
