[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ER014 2119 terms for SP proposal
|
Here is my analysis for SP, same pattern as SC and Trust. ER014 – SP Changes needed Line 121 Extensibility points in the exemplar MAY not be described in
the corresponding text Line 130 WS-SecurityPolicy SHOULD be applicable to any version of
SOAP Line 321 Assertions MAY be used to further qualify a specific aspect
of another assertion. For example, an assertion describing the set of
algorithms to use MAY qualify the specific behavior of a security binding Line 338 Any REQUIRED message elements (e.g. timestamps) in the
wsse:Security header Line 347 Note that a service MAY choose to reject messages despite
them conforming to its policy, for example because a client certificate has
been revoked. Note also that a service MAY choose to accept messages that do
not conform to its policy. Line 365 This section defines properties that are referenced later in
this document describing the RECOMMEDED or REQUIRED attachment points for
various assertions. Line 489 Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as separate references in a signature when
message security is used Line 571 Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as separate references Line 597 Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as separate references Line 628 Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as a combined XPath expression Line 658 Any token assertion MAY also carry an OPTIONAL
sp:IncludeToken attribute Line 659 This attribute indicates whether the token SHOULD be
included Line 664 (in table) an external reference to the token SHOULD be used. Subsequent related messages sent between the recipient and
the initiator MAY refer to Line 673 A token assertion MAY carry a sp:IncludeToken attribute that
requires that the token be included in the message Line 684 then references to that token are REQUIRED to contain all
the specified reference types. Line 691 Any token assertion MAY also carry an OPTIONAL sp:Issuer
element Line 696 Any token assertion MAY also carry an OPTIONAL sp:IssuerName
element. Line 703 While both sp:Issuer and sp:IssuerName elements are OPTIONAL
they are also mutually exclusive Line 706 Any token assertion MAY also carry an OPTIONAL wst:Claims
element Line 710 This element indicates the REQUIRED claims that the security
token MUST contain in order to satisfy the requirements of the token assertion. Line 713 Individual token assertions MAY further limit what claims
MAY be specified for that specific token assertion. Line 716 As long as the union of all tokens in the received message
contains the REQUIRED set of claims from REQUIRED token issuers the message is
valid according to the receiver’s policy. Line 736 This boolean property specifies whether derived keys SHOULD
be used as defined in WS-SecureConversation Line 900 Note: The IssuedToken MAY or MAY NOT be associated with key
material and such key material MAY be symmetric or asymmetric. Line 902 Services MAY also include information in the
sp:RequestSecurityTokenTemplate element Line 1180 then either the sp:SecureConversationToken or the
sp:IssuedToken assertion SHOULD be used instead Line 1187 Because this token is issued by the target service and MAY
NOT have a separate port Line 1379 the sp:IssuedToken assertion SHOULD be used instead Line 1451 the sp:IssuedToken assertion SHOULD be used instead Line 1597 This property specifies the algorithm suite REQUIRED for
performing cryptographic operations with symmetric or asymmetric key based
security tokens. Line 1635 This property indicates the order in which integrity and
confidentiality are applied to the message, in cases where both integrity and
confidentiality are REQUIRED Line 1639 This boolean property specifies whether the signature MUST
be encrypted. Line 1641 The primary signature element is NOT REQUIRED to be
encrypted if the value is ‘true’ Line 1646 This boolean property specifies whether signatures MUST
cover the token used to generate that signature. Line 1650 It is RECOMMENDED that assertions that define values for
this property apply to [Endpoint Policy Subject]. Line 1653 This boolean property specifies whether signature digests
over the SOAP body and SOAP headers MUST only cover the entire body and entire
header elements. Line 1661 It is RECOMMENDED that assertions that define values for
this property apply to [Endpoint Policy Subject]. Line 1674 then it SHOULD appear before the ds:Signature and
xenc:ReferenceList elements Line 1700 then it SHOULD appear before the ds:Signature and
xenc:ReferenceList elements Line 1719 However, the xenc:ReferenceList is NOT REQUIRED to appear
before independently encrypted tokens such as the xenc:EncryptedKey token as
defined in WSS Line 2133 Additional tokens MAY be specified to augment the claims Line 2134 This section defines seven properties related to supporting
token requirements which MAY be referenced by a Security Binding Line 2145 Supporting tokens MAY be specified at a different scope than
the binding assertion Line 2148 the sender SHOULD merge the requirements by including all
tokens Line 2152 all the tokens SHOULD sign and encrypt the various message
parts Line 2161 To illustrate the different ways that supporting tokens MAY
be bound to the message Line 2165 Even before any supporting tokens are added, each binding
requires that the message is signed using a token satisfying the REQUIRED usage
for that binding Line 2171 Note: if REQUIRED, the initiator MAY also include in the
Security header the token used as the basis for the message signature (Sig1),
not shown in the diagram Line 2178 Supporting tokens are included in the security header and
MAY OPTIONALLY include additional message parts to sign and/or encrypt Line 2229 Signed tokens are included in the “message
signature” as defined above and MAY OPTIONALLY include additional message
parts to sign and/or encrypt Line 2283 produced from the message signature and MAY OPTIONALLY
include Line 2339 This assertion MAY OPTIONALLY include additional message
parts to sign and/or encrypt Line 2345 If transport security is used, the token (Tok2) is included
in the Security header and the signature (Sig2) SHOULD cover the message
timestamp as illustrated below Line 2485 There are several OPTIONAL aspects to the WSS: SOAP Message
Security specification Line 2496 a token MAY be referenced using different mechanisms Line 2551 This boolean property specifies whether
wsse11:SignatureConfirmation elements SHOULD be used Line 2634 These assertions relate to interactions with a Security
Token Service and MAY augment the behaviors defined by Line 2649 A challenge issued by the server MAY increase the number of
messages exchanged by the client and service Line 2656 This boolean property indicates whether client entropy is
REQUIRED to be used as key material for a requested proof token. A value of
'true' indicates that client entropy is REQUIRED. A value of 'false' indicates
that client entropy is NOT REQUIRED Line 2661 This boolean property indicates whether server entropy is
REQUIRED to be used as key material for a requested proof token. A value of
'true' indicates that server entropy is REQUIRED. A value of 'false' indicates
that server entropy is NOT REQUIRED Line 2881 Policy MAY be embedded inside an Issued Token assertion, or
acquired out-of-band. There MAY be an explicit trust relationship between the
Server and the STS. There MUST be a trust relationship between the Client and
the STS. Line 2885 client-specific parameters that MUST be understood Line 2898 The Client MAY augment or replace the contents of the RST Line 2902 The Issued Token Policy Assertion contains elements which
MUST be understood by the Client. The assertion contains one element which
contains a list of arbitrary elements which SHOULD be sent along to the STS Line 2908 All items are OPTIONAL , since the Server and STS MAY
already have a pre-arranged relationship Line 3808 A wsse:UsernameToken MAY be encrypted when a transport
binding is not being used English usages – No changes required Line 51 “element are required to be satisfied”
(describes an example) Line 57 “required to be encrypted” (describes an
example) Line 318 “For example, it may be common that the
mechanism is constant for an endpoint” Line 719 “For example if the receiver’s policy
contains two token assertions, one requires” Line 834 “For example, the initiator may need” Lines 2478, 2480, 2482 “must be included”
(describes an example) All un-capitalized terms in section 12 are English and
properly not capped, no change Schema exemplar description changes Many issues with OPTIONAL and REQUIRED in the schema
exemplar descriptions. These are straightforward and I recommend that if the
above is acceptable that the editors simply produce a redline version for
review. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]