RE: First draft

[George_Robert_Blakley_III@tivoli.com]

All

>1.  For me, the comment that all assertions must be  protected using the
XML signature facility
>is too  strong.
>There has been a discussion about this on both the use-case and
core-assertion mailing lists.
>The issue is that if two parties need high performance, they might
establish a secure session
 >and exchange unsigned assertions, relying on the secure session  protocol
to protect and
 >validate them.

Again, I'll put my 2 cents worth in on this.

SIGNING AND/OR ENCRYPTING ASSERTIONS MUST BE OPTIONAL AT THE LEVEL OF THE
ASSERTION
TOKEN DEFINITION.

There are scenarios where assertions should not be signed OR encrypted
either becuase performance would
be unacceptable, or because a trusted link has already been set up which
obviates the need for signing and
encryption, and in these cases there should be no requirement to implement
an additional crypto facility at the
SAML level.

SIGNING AND/OR ENCRYPTING ASSERTIONS *MAY* BE MANDATORY IN *SOME* BINDINGS.

Individual bindings will have known security properties. If these
properties are insufficient to protect assertion
tokens, then the binding should specify that it is mandatory IN THE CONTEXT
OF THE BINDING that
the optional (AT THE LEVEL OF THE ASSERTION TOKENS) signature and/or
encryption fields of the tokens
be used, and be used in a particular, specified way.

--bob

Bob Blakley
Chief Scientist
Enterprise Solutions Unit
Tivoli Systems, Inc. (an IBM Company)


"Edwards, Nigel" <Nigel_Edwards@hp.com> on 03/01/2001 12:45:58 PM

To:   Tim Moses <tim.moses@entrust.com>,
      "'security-protocol@lists.oasis-open.org'"
      <security-protocol@lists.oasis-open.org>
cc:
Subject:  RE: First draft




Hi  Tim,
I have  just read this document and attach a version of the document with
my  comments in line using the microsoft word "comments facility".  Use
view->comments to see these.

I have  two main comments.

1.  For me, the comment that all assertions must be  protected using the
XML signature facility
is too  strong.
There has been a discussion about this on both the use-case and
core-assertion mailing lists.
The issue is that if two parties need high performance, they might
establish a secure session
 and exchange unsigned assertions, relying on the secure session  protocol
to protect and
 validate them.

2.  I think we are a bit light on error codes. I have tried to identify a
few more  at appropriate places.
(Example  unknown entitlement assertion reference).

Other comments in  line as explained above.

Regards,
Nigel
-----Original Message-----
From: Tim Moses  [mailto:tim.moses@entrust.com]
Sent: Wednesday, February 14, 2001  9:00 PM
To:  'security-protocol@lists.oasis-open.org'
Subject: First  draft



Colleagues - Apologies.  Some of you were not  correctly included in the
"protocols" mail list (my fault).  It is  corrected now.  Please check out
the mail I sent today.  Best  regards.  Tim.

http://lists.oasis-open.org/archives/security-protocol/200102/threads.html

---------------------------------------------------------------------------------------

Tim Moses
Tel:  613.270.3183

(See attached file: OasisProtocolDraftNigelComments.doc)

Microsoft Word 4