New Issue: Editorial Comments on WS-Trust

[Frederick Hirsch <frederick.hirsch@nokia.com>]

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSION THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. 

The issues coordinators will notify the list when that has occurred.

Protocol:  ws-trust 

See ws-trust-1.3-spec-ed-01-r03-diff.doc at  http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/16566/ws-trust-1.3-spec-ed-01-r03-diff.doc

Artifact:  spec 

Type: editorial 

Title: Editorial comments on WS-Trust

Description:

Editorial comments on WS-Trust specification

Related issues: none

Proposed Resolution:

1) Section 1.2, Remove line 54, modify line 55 to be

"Establishing, managing and assessing trust relationships."

("Managing trusts" is unclear).

2) Section 1.4

Neither schema (line 62) or wsdl (line 65) are located in the oasis docs directory. Should a draft be placed there?

3) Remove material in 1.5 from lines 109-115

Replicated in next section where it belongs.

4) Line 139 add [ for WS-PolicyAttachment

5) line 261 s/. As well,/ or/

6) Line 457, s/As well, /Additional

7) move lines 478-480 to 472, replace "As well, it is" with "It is also"

The mechanisms defined in this specification apply to both symmetric and asymmetric keys. As an example, a Kerberos KDC could provide the services defined in this specification to make tokens available; similarly, so can a public key infrastructure.  In such cases, the issuing authority is the security token service.

It should be noted that in practice, asymmetric key usage often differs as it is common to reuse existing asymmetric keys rather than regenerate due to the time cost and desire to map to a common public key.  In such cases a request might be made for an asymmetric token providing the public key and proving ownership of the private key.  The public key is then used in the issued token.

 A public key directory is not really a security token service per se; however, such a service MAY implement token retrieval as a form of issuance.  It is also possible to bridge environments (security technologies) using PKI for authentication or bootstrapping to a symmetric key.

8) Line 490, replace "Subsequent" with "Additional". Line 492, remove " (e.g. multiple simultaneous exchanges) "

9) Line 560 s/post-dated/postdated/

10)  Line 694, change last OK in table to "Issuer scope".

11) Line 743, s/and are/that is

12) Line 762,  Is link really to Section 6.1 or to 4.1?

13) Line 878, 

Replace "Two or more RSTR elements are returned in the collection." with "Each RequestSecurityTokenResponse element is an individual RSTR."

Add text "Two or more RSTR elements are returned in the collection." to end of line 876, for description of collection.

14) Line 927 add "This element schema is defined using the RequestSecurityTokenResponse schema type."

(this merely reiterates line 916 in the text describing the element).

15) Line 1128 indicate request and response separately.

16) Table entries at 1219 s/request/Trust service

17) Table 1225, is example missing token to be validated?

18) Any additional requirements/description on validation of envelope needed in section 7?

e.g. validate for specific role?

19) Is ws:LChallenge correct at line 1352?

20) Section 8.6, generally sign with private key associated with certificate, not certificate... (lines 1447, 1484) 

21) 1699 s/binding/other bindings

regards, Frederick

Frederick Hirsch

Nokia