ER012 2119 terms for Trust proposal

Same
pattern as the SC proposal. I should have the SP one by tomorrow. 

ER012 – Trust

Changes needed

Line 212

Authentication of requests is
based on a combination of OPTIONAL network and transport-provided security and
information (claims) proven in the message

Line 231

This model is illustrated in
the figure below, showing that any requestor MAY also be a service, and that
the Security Token Service is a Web service (that is, it MAY express policy and
require security tokens).

Line 242

In the figure above the arrows
represent possible communication paths; the requestor MAY obtain a token from
the security token service, or it MAY have been obtained indirectly. The
requestor then demonstrates authorized use of the token to the Web service. The
Web service either trusts the issuing security token service or MAY request a
token service to validate the token (or the Web service may validate the token
itself).

In summary, the Web service
has a policy applied to it, receives a message from a requestor that possibly
includes security tokens, and MAY have some protection applied to it using
[WS-Security] mechanisms.

Line 254

In brokered trust models, the
signature MAY NOT verify the identity of the claimant – it MAY verify the
identity of the intermediary, who MAY simply assert the identity of the
claimant.

Line 259

The trust engine MAY need to
externally verify or broker tokens

Line 265

In this specification we
define how security tokens are requested and obtained from security token
services and how these services MAY broker trust and trust policies so that
services can perform step 3.

Line 280

As part of a message flow, a
request MAY be made of a security token service to exchange a security token
(or some proof) of one form for another

Line 289

the security token service
generating the new token MAY NOT need to trust the authority that issued the
original token provided by the original requestor since it does trust the
security token service that is engaging in the exchange for a new security
token

Line 300

An administrator or other
trusted authority MAY designate that all tokens of a certain type are

Line 303

or the security token service
MAY provide this function as a service to trusting services.

Line 306

These mechanisms are
non-normative and are NOT REQUIRED in any way.

Line 313

Trust hierarchies –
Building on the trust roots mechanism, a service MAY choose to allow
hierarchies of trust so long as the trust chain eventually leads to one of the
known trust roots. In some cases the recipient MAY require the sender to
provide the full hierarchy. In other cases, the recipient MAY be able to
dynamically fetch the tokens for the hierarchy from a token store.

Line 335

or they MAY return a token
with their chosen parameters that the requestor MAY then choose to discard
because it doesn't meet their needs

Line 339

Other specifications MAY
define specific bindings and profiles of this mechanism for additional
purposes.

Line 341

in some cases an anonymous
request MAY be appropriate

Line 343

If not a fault SHOULD be
generated (but is NOT REQUIRED to be returned for denial-of-service reasons).

Line 415 (this one changes a
“shouldn’t”)

In general, the returned token
SHOULD be considered opaque to the requestor. That is, the requestor SHOULD NOT
be required to parse the returned token.

Line 429

and the value of the OPTIONAL
@Context attribute

Line 432

In such cases, the RSTR MAY be
passed in the body or in a header block.

Line 475 

the ellipses below represent
the different containers in which this element MAY appear

Line 518

This binding supports the
OPTIONAL use of exchanges during the token acquisition process as well as the
OPTIONAL use of the key extensions described in a later section. 

Line 522

the following OPTIONAL
elements

Line 741

the following OPTIONAL
elements

Line 561

This REQUIRED attribute
contains a URI that indicates the syntax used to specify the set of requested
claims along with how that syntax SHOULD be interpreted.

Line 574

The format is assumed to be
understood by the requestor because the value space MAY be

Line 580

The issuer is not obligated to
honor this range – they MAY

Line 587

The difference in time SHOULD
be minimized.

Line 697

Each request MAY generate more
than one RSTR sharing the same Context attribute value

Line 711

Note: that these operations
require that the service can either succeed on all the RST requests or MUST NOT
perform any partial operation.

Line 722

If any error occurs in the
processing of the RSTC or one of its contained RSTs, a SOAP fault must be
generated for the entire batch request so no RSTC element will be returned.

Line 833

The token issuer can
OPTIONALLY provide

Line 990

As a result, the
proof-of-possession tokens, and possibly lifetime and other key parameters
elements, MAY be different

Line 1071

If confidentiality protection
of the <wst:IssuedTokens> header is REQUIRED then the entire header MUST
be encrypted using the <wsse11:EncryptedHeader> construct.

Line 1131

and the OPTIONAL
<wst:Lifetime> element

Line 1167

This OPTIONAL element
indicates that returned tokens SHOULD allow requests for postdated tokens. 

Line 1225

If a client needs to ensure
the validity of a token, it MUST validate the token at the issuer.

Line 1292

this section defines an
OPTIONAL binding

Line 1354

The result MAY be a status, a
new token, or both.

Line 1370

The request provides a token
upon which the request is based and OPTIONAL tokens. As well, the OPTIONAL
<wst:TokenType> element

Line 1371

This MAY be any supported token
type or it MAY be the following URI indicating that only status is desired:

Line 1378

which is OPTIONAL

Line 1467

However, there are many
scenarios where a set of exchanges between the parties is REQUIRED prior to
returning (e.g., issuing) a security token.

Line 1487

with the issued security token
and OPTIONAL proof-of-possession token

Line 1502

(and MAY contain initial
negotiation/challenge information)

Line 1504

Optionally, this MAY return
token information

Line 1572

Exchange requests MAY also
utilize existing binary formats

Line 1579

ellipses below indicate that
this element MAY be placed in different containers

Line 1602

In some cases it MAY be
necessary to provide a key exchange token so that the other party (either
requestor or issuer) can provide entropy or key material as part of the
exchange. Challenges MAY NOT always provide a usable key as the signature may
use a signing-only certificate.

Line 1606

The section describes two
OPTIONAL elements

Line 1608

ellipses below indicate that
this element MAY be placed in different containers

Line 1617

This OPTIONAL element is used
to indicate that the receiving party (either the original requestor or issuer)
SHOULD provide a KET to the other party on the next leg of the exchange.

Line 1822

This MAY be built into the
exchange messages

Line 1832

To this end, the following
computed key algorithm is defined to be OPTIONALLY used in these scenarios

Line 1837

However, until the exchange is
actually completed it MAY be (and is often) inappropriate to use the computed
keys. As well, using a token that hasn't been returned to secure a message may
(no change, English) complicate processing since it crosses the boundary
of the exchange and the underlying message security. This means that it MAY NOT
be appropriate to sign the final leg of the exchange using the key derived from
the exchange.

Line 1874

This <wst:CombinedHash>
element is OPTIONAL

Line 1878

since all types of requests
MAY issue security tokens they could apply to other bindings

Line 1924

The syntax for these OPTIONAL
elements is as follows

Line 1950

That is, requestors SHOULD be
familiar with the recipient policies

Line 1996

This element either contains a
security token or a <wsse:SecurityTokenReference> element that references
the security token containing the key that SHOULD be used in the returned
token.

Line 2037

EncryptionAlgorithm –
used to indicate the symmetric algorithm that the STS SHOULD use to encrypt the
T (e.g. AES256)

Line 2043

EncryptionAlgorithm –
used to indicate the symmetric algorithm that the STS SHOULD use to encrypt T
for RP (e.g. AES256) 

KeyWrapAlgorithm – used
to indicate the KeyWrap algorithm that the STS SHOULD use to wrap the generated
key that is used to encrypt the T for RP

Line 2052

EncryptionAlgorithm – used
to indicate the symmetric algorithm that the STS SHOULD use to encrypt T for RP
(e.g. AES256)

Line 2059

EncryptionAlgorithm - used to
indicate the symmetric algorithm that the STS SHOULD use to encrypt T for RP
(e.g. AES256)

KeyWrapAlgorithm – used
to indicate the KeyWrap algorithm that the STS SHOULD use to wrap the generated
key that is used to encrypt the T for RP

Line 2140

This OPTIONAL element, of type
xs:boolean, specifies whether the requested security token SHOULD be marked as
"Forwardable”

Line 2145

This OPTIONAL element, of type
xs:boolean, specifies whether the requested security token SHOULD be marked as
"Delegatable".

Line 2224

Arbitrary types MAY be used to
specify participants

Line 2248

OPTINALLY the
<wst:TokenType> element can be specified in the request and can indicate

Line 2363

Other specifications and
profiles MAY provide additional details on key exchange

Line 2376

In these cases both parties
SHOULD contribute entropy to the key exchange by means of the
<wst:entropy> element

Line 2403

If the requestor provides key
material that the recipient doesn't accept, then the issuer SHOULD reject the
request. 

Line 2492

A third party MAY also act as
a broker to transfer keys

Line 2631

The perfect forward secrecy
property MAY be achieved by

English usages – No
changes required

Line 6 “the two parties
must exchange security credentials”

Line 34 “efforts must be
applied to ensure that”

Line 47 “The Web
services trust specification must support a wide variety of security
models”

Line 101 “Note that
readers should be familiar”

Line 208 “message
arrives without having the required proof of claims”

Line 209 “A service can
indicate its required claims and related information”

Line 218 “This allows a
requestor to prove a required set of claims”

Line 220 “to prove
required claims to a service”

Line 222 “may in turn
require their own set of claims”

Line 269 “requestors
should consider”

Line 295 “For example,
the token may be sent” “or the token may have been”

Line 350 “Also, any
required clock synchronization is outside the scope of this document.”

Line 355 “sections 3.1
and 3.2 should be viewed as”

Line 360 “the requestor
MUST prove any required claims to the satisfaction”

Line 412 “It should be
noted”

Line 416 “information
that the requestor may desire”

Line 424 “there are
scenarios where the RSTR must be passed in conjunction with an existing
application message”

Line 430 “should be
noted”

Line 431 “should be
noted”

Line 460 “should be
noted”

Line 470 “should be
noted”

Line 506 “should be
noted”

Line 556 “should be
considered”

Line 639 “To interact
with the manufacturer web service the parts supplier may have to”
(describes an example)

Line 644 “it may be much
more efficient” (describes an example)

Line 645 “especially
when more than two tokens are required”

Line 778 “Typically
tokens allow the use of wsu:Id so this element isn't required”

Line 846 “i.e. it may be
encrypted for the server”

Line 874 “in some
scenarios the key(s) resulting from a token request are not directly returned
and must be computed”

Line 947 “In the example
above, the recipient may place” (describes an example)

Line 954 “no new
proof-of-possession token is required” (describes an example)

Line 1180 “should be
noted”

Line 1246 “should be noted”

Line 1357 “should be
noted” 

Line 1489 “should be
noted”

Line 1519 “For example,
a <wsp:Policy> element may be used”

Line 1527 “should be
noted”

Line 1627 “should be
noted”

Line 1673 “and contains
a random challenge that the requestor must sign” (describes an example)

Line 1799 “a token
should be issued” (describes an example)

Line 1818 “should be
noted”

Line 1835 “it may be
desired”

Line 1916 “In some cases
the service may support” (usage synonymous with might)

Line 1918 “It should be
noted that the issuer's policy indicates if input values must be adhered to and
faults generated for invalid inputs, or…”

Line 1950 “For example,
this might be used to indicate which of the four U.S. government authentication
levels is required”

Line 1955 “should be
noted”

Line 1958 “indicates the
size of the key required specified in number of bits”

Line 2072 “The token
should be signed using…” “The proof should be
encrypted…” (describes an example)

Line 2206 “should be
noted”

Line 2257 “Care should
be taken”

Line 2300 “should be
noted” “should be careful”

Line 2365 “Care must be
taken”

Line 2369 “should only
be considered”

Line 2492 “For example,
a requestor may”

Line 2559 “there may be
a desire”

Line 2628 “Of course, a
freshly generated public key must still be authenticated”

Line 2634 “Care should
be taken”

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.