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.