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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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