[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 34: Editorial Comments on WS-Trust
Logged as issue 34. Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 From: Frederick Hirsch
[mailto: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 Hirsch Nokia
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]