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.