[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Update to WSS SAML Interop Scenarios w holder-of-key
Richard, I'd like to pass on the following comments/questions on the 2nd draft of the WSS SAML interop document. Comments on Scenario 1 (sender Vouches): 1. para starting at line 109 - The comments regarding SSL cause me to wonder if we should have a scenario that explicitly tests sender-vouches where the sender uses SSL to prove its identity (1 hop) to the SOAP msg recipient and to bind the assertion to the SOAP msg. Maybe scenario 1 should be split into 2 cases one with SSL and one without. I propose that we consider the existing scenario 1 independent of SSL (and factor all the SSl considerations out of its description) 2. line 121: In this case, if a certificate is being sent, it is not being sent to verify a (XML-DSIG) signature. Its does not seem that any of C1.2 and C1.3 and C1.4 would pertain to the non-SSL case. 3. line 136-137: "the request contains a plaintext SAML assertion...", I think we want the message to contain a SAML assertion containing one subject statement. I am not sure we need to say "plain text", and I don't see the value of checking the subject against a catalog of trusted users or the authority against the catalog of issuers? It seems that we could be less restrictive for this basic case of - can we exchange a SAML assertion in a SOAP msg. 4. All of the elements of the table beginning at line 147 are marked mandatory. Do we really nead Timestamp and Conditions. IMO, we should drop would both of these (or at least Conditions). As I mentioned above, it would also seem that we should be flexible about the type of Assertion, as long as it contains a sender-vouches confirmed subject statement. 5. As noted above do we need C.4.2.1 Timestamp 6. C.4.2.3 regarding Issuer Attribute; why must the Issuer attribute match a particular value; especially given that we are not requiring that the assertion be signed. 7. 4.2.3.1 Why are we requiring that a Conditions element be present 8. 4.2.3.2 NameIdentifier - I would opt for just requiring an Assertion containing a single sender-vouches confirmed subject statement. 9. C.4.3 The WSS Saml Token profile is a little out of date WRT to the core's description of error codes (and the need to send responses). It currently does not define a circumstance that maps to "FailedAuthentication". Perhaps it should. As currently written, the profile describes mappings of problems to faults that would likely result in a mapping to FailedCheck under the indicated circumstances. In any case, we likely do NOT need to mandate what fault to return when we are doing something optional. If we do need to do this, we need to make sure the profile is in sync with the correspondence we are requiring. 10. 4.3.3 Assertion - I don't see the value of this requirement. Ditto for c.3.3.1 Conditions, and likely also c.4.3.3.2 Username [Just a comment] This may fall into the category of you teaching us how to crawl before we try to run, but I think it would be good if we could use STR's instead of embedded assertions for these scenarios. I realize it may be impractical for us each to have an authority online at which we could dereference the references. That said, IMV, interop-ing with references is likely at least as important as using embedded assertions, and we likely should devise a plan for testing with references (even if we fake out the authorities). 11. C.7 Expected Security properties - I don't think there is any requirement that the assertion be related to the "party" as described. Sender vouches, allows a sender to vouch for the contents of an assertion, independent of whether the subject identified by the assertion is itself. Comments on Scenario 2 (sender-Vocuhes signed): 1. 274: I would prefer that the certificate be referenced from the msg as apposed to being included in it. 2. D.1.1 UserName- List - as noted for scenario 1, I don't see why it is necessary to restrict the subjects. Is this a carryover form username password? 3. D.1.2 IssuerName - List - perhaps this section should be removed 4. D.1.4 Requester Cert Value - IMO, the SSL qualification should be removed. 5. D.3 general message flow - same comments about plain text assertion, and I would prefer that the certificate be referenced from the signature not "contained in the signature". Also, do we expect the relying party to validate the certificate (especially if it is referenced)? IF not, we should remove "validates the issuer certicate". In any case, we likely should call the certicate the "signer's certificate". 6. Table begining on 310 - Again, I don't think Do we need to require timestamps and conditions? The table also shows a binary security token (note that it is not contained in the signature), IMO, it should be referenced from the signature. As noted above, I would also prefer that we accept any sender-vouches confirmed subject statement. 7. Section D.4.2.4.1 requires the use of a relative URI to reference the Assertion that must be signed (I would prefer that we point to an STR, and that we feature the STR transform in the data reference). 8. Line 335 KeyInfo: same comment, I would prefer that we not include the certificate, but simply include its identifier. 9. 343: same comment about requiring an AuthenticationStatement. This seems to prescriptive. 10. D.4.3.5 defines recommended processing that I don't think should be recommended. There need be no correlation between the issuer (of the assertion) attribute and the subject of the cert or the subject of the assertion. If I understand the scenario, the assertion is not signed, so the value of the issuer attribute is questionable, and in sender vouches, whoever signed the msg + assertion is vouching for their contents and binding, including the subject of the assertion; which may be not be the signer. Comments on Scenario 3 (holder of key): 1. line 492: I would prefer that the certificate used to confirm the assertion be identified within the subject confirmation element as apposed to being contained within it. I don't have the SAMl spec at hand, but if we are going to say contained, we need to make sure cert containment is supported by SAML subject confirmation. 2. Sections E.1.1 UserName-list may be important to the methodology but it might just be a carry-over from the username password scenarios. I would recommend removing or reducing the significance of the section (in this context). 3. Line 503: Requestor cert value - we need to provide the cert, but its identification is accomplished within the subject confirmation element of the assertions. 4. Line 521: This para. implies some ordering of processing by its use of the word "finally"; although I expect that I may be reading more into the description that was intended. FWIw, wouldn't the order of processing be different that that proposed. Verify the signature on the asertion (incluing cert validation), verify the signature on the msg (including cert validation) and thus establish the subject(s) associated with the invocation. 5. same comments as for the other scenarios questioning the need for Timestamp and Conditions. 6. IMO, requring authentication statements with holder-of-key is difficult to justify as why go through the trouble of obtaining an authentication statement if you are going to be required to prove your identity to use it. 7. line 604: I think the value of the issuer attribute within the assertion must always match the cert used to verify the assertion signature. Ron >Attached is the 2nd draft of the WSS SAML Interop Scenarios. >This contains the holder-of-key scenario, which was not >included in the first draft, as well as some minor updates >to the original version. > >Comments are welcome and no additional updates are planned >until comments are received. > > Rich Levinson ><snip> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]