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] | [List Home]

Subject: Re: [wss] Update to WSS SAML Interop Scenarios w holder-of-key


I'd like to pass on the following comments/questions on the 2nd draft of 
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

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

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 

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. Why are we requiring that a Conditions element be present

8. 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 
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. 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 

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. 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 
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 
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 
Verify the signature on the asertion (incluing cert validation), verify 
the signature
on the msg (including cert validation) and thus establish the subject(s) 
with the invocation.

5. same comments as for the other scenarios questioning the need for 
Timestamp and

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.


>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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]