RE 1 and 2: We discussed this on one of the calls and edits were made to
the core specification to better explain the use of
SecurityTokenReference. Can you take a look there and see if that
clears up either of the issues or if you still think we need additional
text in the token profile.
-----Original Message-----
From: Tim Moses [mailto:]
Sent: Tuesday, March 11, 2003 9:17 AM
To: 'WS-Security'
Colleagues - The most recent update of the X.509 profile was posted on
30
Jan. I made the following comments on 11 Feb. All the best. Tim.
1. Is it desirable to use the same element as a reference and a
referent? I
am referring t=
o the use of wsu:id in SecurityTokenReference and in the
BinarySecurityToken. It wou=
ld preclude one from making a reference from a reference, at the very
least.
2. In Section 3.4, the proposal should be more fully described. I think
it
says that a ds=
:signature should contain the optional ds:keyInfo, which (in turn)
should
contain a S=
ecurityTokenReference, whose wsu:id attribute matches the wsu:id of the
BinarySecu=
rityToken. Why would one not just put the wsu:id in the ds:keyName
element
of the ds:ke=
yInfo?
3. Under what circumstances would one need to reference an X.509
certificate
containi=
ng an =22encryption=22 key? Perhaps, to provide the encryption key of
the
message ori=
ginator? Personally, I prefer to use a policy mechanism for this
purpose.
Should not=
this profile describe how to convey a SKId or IssuerSerial?
4. It may be necessary to convey more than one certificate. It should
be
explained whic=
h elements have to be duplicated in order to convey multiple
certificates.
If there ar=
e multiple certificates and CRLs, then they are not all referenced
directly
by a Securi=
tyTokenReference. Rather, they may be referenced by conventional X.509
techniques=
from another certificate. This should be described.
5. In Section 3.6, it isn't clear to me why are we stating such a soft
requirement for erro=
r codes? I suppose it is only necessary that both parties agree how to
indicate that the=
re IS an error. However, is there a good reason for not requiring that
implementations=
support some common codes?
All the best. Tim.
-----------------------------------------------------------------
Tim Moses
613.270.3183
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
