[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] comments on initial specifications
Generic Comments on the bindings documents: 1. The status section at the front of each of the 3 bindings documents and the core should be reviewed, to ensure that their declarations of where to look for IPR terms is accurate. They all currently point us in words to the SS TC (as apposed to the WSS TC), and moreover the URL appears not to be TC or technology specific. Comments on the WSS Core Specification: 1. Lines 23-24 I don't see how what follows "For example" is related to "no specific security token is required"; mostly because I'm not sure that the examples actually qualify as a security token since they are "proofs", of which only one form is defined as a security token by the specification. 2. Lines 115-116 refers to three "provided" mechanisms one of which is "security token propagation". This term is never mentioned again by the specification (so it is unclear what is meant by it). 3. line 123 should be removed. 4. lines 125-126 seem to overstate the goal of the specification in light of line 116. 5. lines 132-134 May be accurate, but I don't see how they "summarize" any ealier text. 6. line 147 contrary to this non-goal, key conveyance seems to be the primary feature/use model of a security token (as defined by this spec). 7. line 174 if a security token has some role in identifying a key, the definition should reflect it (or the concept of security token should be brodened to include things that are not focused on keys) 8. lines 179-180 a POP may not proove anything about the sender, as is the case with a signature. A simple signature can only provide POP of the signature writer, who may not be the sender. 9. 182-183 Integrity can be at risk without "transit". The mechanisms in this spec describe how integrity can be proved and preserved independent of transit/transport. 10. Lines [198-199] of the core state the following: "This document specifies an abstract message security model in terms of security tokens combined with digital signatures as proof of possession of the security token (key)." The word "key" in parentheses seems to imply that the fundamental purpose of security tokens in the ws-security model is to convey keys. This would seem to preclude security tokens whose purpose is other than to convey or bind a key to an identity or entity. The more general notion of security tokens being used to convey claims does not do justice to their apparent role in identifying "the key". 11. Line [215-221] of the core state the following: "One special type of unendorsed claim is Proof-of-Possession. Such a claim proves that the sender has a particular piece of knowledge that is verifiable by, appropriate roles. For example, a username/password is a security token with this type of claim. A Proof-of-Possession claim is sometimes combined with other security tokens to prove the claims of the sender. Note that a digital signature used for message integrity can also be used as a Proof-of-Possession claim, although in this specification does not consider such a digital signature as a type of security token." a. Why is it necessary to special case a Username/Password POP token? a POP should be a fundamental type or relationship within the ws-security token model. As a strawman, a POP might be modeled as a tuple composed of 3 elements (some being optional): i. a set of one or more claims that (among other thins) identify the key that must be proven to gain access to the claims ii. a replay protection element (e.g. a timestamp + nonce) iii. a crytographic element computed with the key identified in i, and that may reference the replay protection element and any msg content to be bound to the POP. This element would be a typed element with an XML DSIG being one type, a password digest, or a plain password could be other forms. b. Why is it necessary to treat XML Signature elements as other than security tokens? One reason may be that for XML signatures to be a full fledged wsse (XML) security token, an effective SecurityTokenReference form for signatures would need to be specified. Doing so would support location from the header of Signature elements in other (than the wsse header) parts of the SOAP message/document. 12. Given the current core specification, how can a Signature element occuring outside of the header be referenced (as in, identified for validation) from within a wsse header? 13. lines 332, 336, 349 each contain a grammatical error 14. line 373 Question how is the "final destination" for a msg defined or recognized? Is this a reference to ws-routing semantics? 15. lines 564-565 what does it mean to process a BinarySecurityToken? Presumably this means so as to detrmine if you support the specific token type. 16. lines 566-570 How does it help to include the prefixes in the token, if the token is not part of the signature? That is it is referenced from the signature? 17. lines 601-603 should refer to POP instead of saying "towards this end". 18. lines 637-638 it would help to qualify this, as not all reference forms will be supported by all implementations 19. line 662 It would seem that a reference element should have an @any to allow for attribute extensibility. 20. section 7.4 keyInfo lines 705 why the focus on binary tokens? XML tokens should also be supported 21. Section 7.6 this should probably be rephrased to include information on how to produce key references given an understanding of how references will be processed? 22. lines 736-734 It would help to clarify this (at least for me) as I don't understand. It appears that signatures over security tokens in the header would not necessarily be subject to the types of problems that I think are calling for detached signatures. Stopped at Section 9. Comments on the SAML Binding/Profile: 5. section 3.3 neglected to include the use of the URI attribute (on SecurityTokenReference) from the SS TC submission. This attribute is necessary to identify the responder at which to dereference the assertionID/reference. 6. Should there be a reference form that carries what amounts to a SAML assertion Query such that the sender does not need to have acquired the assertion (to be able to apply it to a request)? 7. A use case where an encrypted shared secret session key, is conveyed in a subject confirmation element within a SAML authentication assertion should be added to the SAML binding. The subject would demonstrate knowledge of the key by signing something with it. This form of SAML assertion would be used in a manner analogous to a kerberos service ticket.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC