[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] F2F-Issues 8
ID | Type | Status | Issue | Resolution | Owner(s) |
3 | Technical | Open | Proposal to Label Tokens to Indicate Their Semantics |
F2F - Open Ronald Monzillo and Anthony Nadalin will send out a proposed set of changes. |
Ronald Monzillo |
26 | Technical | Pending | Core: What does it mean to process a BinarySecurityToken? | F2F - Tony/Ron to get with Ron for final wording. | Anthony Nadalin, Ronald Monzillo |
28 | Technical | Open | SAML Binding: Include the use of the URI attribute (on SecurityTokenReference) from the SS TC submission | F2F - Robert, Don, Prateek to provide proposal | Prateek |
36 | Technical | Pending | In section 10.2.2, why not just specify that the <Created> element type be xsd:dateTime? |
F2F Tony. TC to review. |
TC |
46 | Technical |
Postponed Pending QoP discussion |
WSDL definitions - It seems to me that a stand-alone specification should just
define the semantics of its elements. If an application wants those
semantics, then the application WSDL should specify the header as being required. |
F2F after QoP discussion |
TC |
47 | Technical | Pending | Add example. Working Draft 3. Page 21, Section 7.1, lines 644-648, recommends that <wsse:SecurityTokenReference> element should be used as direct children of <ds:KeyInfo> elements to retrieve signing and encryption certificate when using XML Signature and XML Encryption. Although in section 8.4, there is a XML Signature example for using <wsse:SecurityTokenReferences> element within the <ds:signature>'s <ds:KeyInfo> element, there is no examples provided to using SecurityTokenReference element for XML Encryption in section 9. E.g., Section 9.2 does have a <wsse:KeyIdentifier> contained within the <xenc:EncryptedKey> element. However, it does not have the <wsse:securityTokenReference> element encapsulating the <wsse:KeyIdentifier> as specified in section 7.3. |
F2F Tony to update.. |
Zahid Ahmed |
52 | Technical | Pending | The example in section 3.4 (line 278) seems to have been set up to do a reference bywsu:id attribute value, although the reference is done by URI where the value of theURI is the attribute value. Is this the prefered use model? or would we expect a simpleSTR with a wsu:id value as apposed to a Direct reference/URI to be used? The description of key identifiers seems to imply that Direct references are theprefered form of reference, and where they cannot be used a key identifier isrecommended. |
F2F Chris to provide text. Profile document editors to define what key names and key identifier are. |
Ronald Monzillo |
55 | Technical | Pending | Is it really appropriate to endorse a claim via encryption? Perhaps line 209 in
3.1 should be changed to read: "that is digitally signed by the authority." Editorial - line 362 in 4.2, spell out "Post-Schema Validation InfoSet". I guess this last paragraph says that for non-schema aware processors, support for wsu:Id is optional but recommended? Wouldn't it be better to require support regardless of implementation? |
F2F - Chris/Fredrick to work to with Tony to improve language over encryption. |
Frederick Hirsch |
56 | Technical | Pending | Create a wsu Appendix |
F2F - Create new Appendix that provides explanation. |
Robert Philpott |
59 | Technical | Open | Various editorial comments on XrML binding |
F2F - G to review with Thomas. |
Thomas DeMartini |
60 | Technical | Open | Proposal for processing rules. |
F2F - G to review with Thomas. |
Thomas DeMartini |
61 | Technical | Open | Updated to section 8. |
F2F - Frederick to review with Tony in the afternoon. |
Frederick Hirsch |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC