OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]