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: Update to WSS SAML Interop Scenarios w new SSL scenario + response to comments

Draft 3 WSS SAML Interop spec is attached and has been updated to
divide the first scenario into 2 scenarios:

	1. Minimal SAML scenario
	2. SSL SAML scenario

Diagrams have also been added to each scenario to give context.

In addition, below are my responses the comments that were received 
from Ron Monzillo and where indicated those responses are reflected
in updates to the document.

Comments to draft 3 are wlecome.

	Rich Levinson

-----Original Message-----
From: Ron Monzillo [mailto:ronald.monzillo@sun.com] 
Sent: Monday, November 03, 2003 6:52 PM
To: Levinson, Richard
Cc: 'wss@lists.oasis-open.org'; 'hlockhar@bea.com'
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 the
interop document.

	Note: Ron's comments for scenarios 1 and 2 have line numbers
	that refer to the first draft of the spec. The appropriate line
	numbers in the second draft which is what is now posted are included
	in parentheses above the original for convenience.

Comments on Scenario 1 (sender Vouches):

                    (v2: 124)
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

	Scenario 1 is now divided into 2 scenarios, so there are now
	a total of 4 scenarios which are:

		Scenario 1. Sender-Vouches: Unsigned
		Scenario 2. Sender-Vouches: Unsigned: SSL
		Scenario 3. Sender-Vouches: Signed
		Scenario 4. Holder-of-Key:  Signed


   (v2: 136)
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.

	For scenario 1 refs to SSL are removed C1.3, C1.4. However, I left
	C1.2 there because the recipient probably should have a list of SAML

	assertion issuers that they will accept assertions from - in the
	scenario, the Issuer attr is the only info the recipient has
	the source of the assertion and the only basis for accepting or
rejecting it.

	For scenario 2, the text of 4.1.4 was modified to indicate purpose
	cert is for Requester identification. 

   (v2: 151-152)
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
assertion in a SOAP msg.

	A diagram has been added to each use case to provide context to
	help explain the message flow and the basis for trust to motivate
	the processing model.

	I agree it is not necessary to specify "plain text", however, the
	was to emphasize the vulnerability of the SAML Assertion without any
	additional protection. So, I'll leave it in there for now unless
	there is further sentiment that it should be removed.

	All Requester messages contain only one SAML assertion, which
	only one subject statement. The statement was chosen to be the 
	AuthenticationStatement, because this seems to be a natural way to
	a subject by an issuer. Attribute and Authorization statements seem
	(at least to me) more likely to be used in scenarios where more
	context would be necessary to provide a realistic scenario. But,
	in general, I agree that any type of statement should be acceptable
	so I will remove the Authentication requirement.

	I agree that there is no direct value in checking the user against
	a catalog of trusted users, and that this unnecessarily complicates
	a baseline scenario, so it is removed.

	As far as the Issuer list is concerned, as mentioned above, in
	scenario 1 without the issuer list there is no foundation for 
	a basis for trust and with scenario 2 (ssl) without the issuer
	list our basis for trust is solely ssl and there is no tie to
	using the saml assertion for any purpose, which might lead one
	to question what value saml is adding to the scenario.

	So, the only restriction in this basic case (1 and 2) is simply to 
	convey the assertion in a SOAP message and check that the assertion 
	is issued by a trusted issuer. In the ssl case (2) the
	SSL setup should take care of determining that the Requester
	is valid.

                                                 (v2: 162)
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

	wsu:Timestamp is being kept to be consistent with the other WS

	Conditions can be dropped from scenario 1 to strive for a minimal
	level of operability restrictions. However, for scenario 2
	with NotOnOrAfter and NotBefore is being kept for now because
	it seems to me to be a fundamental attribute of an Assertion that
	duration of validity can be intrinsically controlled and to show
that an 
	issuer can issue an assertion that has limited validity duration. It

	seems to me to be desirable to present the assertions with some
	except in the minimal scenario 1, rather than to be totally stripped

5. As noted above do we need C.4.2.1 Timestamp

	It is optional and explicitly not checked, but was kept to
	conform with the original non-saml WS scenarios.

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.

	For base interoperability it appears to me to be desirable for the 
	Responder to be able to have some criteria for accepting or
	an assertion. The Issuer attribute is probably the minimal case of
	determining whether the Responder gives any weight whatsoever to the
	presence of a SAML assertion in the message. Issuer also provides 
	the foundation for interorganization interoperability by identifying
	the organization that is responsible for issuing the Assertions
	on which the Responder is going to rely.

	Signature is a next level validation criteria - if the assertion is
	not from a trusted issuer or recognized SAML authority, then why
	check the signature. Granted, in the signed use cases that the basis
	of trust IS the signature, it would seem to make sense at that point
	that the Responder have some way to correlate trusted signers and
	trusted issuers, which in many cases will be the same entity.

7. Why are we requiring that a Conditions element be present

	Scenario 1: Conditions will be removed for minimal operation.

	Scenario 2: Conditions will be kept unless there is further
	objection simply to demo interoperability wrt validity intervals 
	that may be specified w assertions. ow assertions are valid
	indefinitely, which may not be typical operation, especially
	for cases where the assertions are intended to be short lived.
	In the SSL case the Requester is effectively signing an 
	assertion and may want to limit the possible duration of its use.

8. NameIdentifier - I would opt for just requiring an Assertion
containing a
single sender-vouches confirmed subject statement.

	NameIdentifier is being dropped as a requirement, but is being
	left in the example as a field that should be ignored. The
	section on SubjectStatement includes phrasing indicating non-reqd
	elements may be present but should be ignored.	

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

	FailedCheck in the core spec refers to failed sigs, which are not 
	occurring in scenarios 1 and 2. I have changed it to
	which is more in alignment with both the profile and with the
	scenario which is now testing only the issuer against the list
	for validation.

10. C.4.3.3 Assertion - I don't see the value of this requirement. Ditto for
Conditions, and likely also c. Username

	Issuer is still being retained as indicated above.
	Conditions and Username are removed from scenario 1 as indicated in 
	reponses above. Username is removed from s2 as well.

[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
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

	I assume you are referring to WS core spec sec 7.4 which shows
	a saml embedded in an STR. This scenario is based on the sv
	case from the profile which doesn't use STRs. 

	If the profile spec were to be updated to include STR for the
	sv example then we could add another use case to demo STR.

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
by the assertion is itself.

	I agree there is no need to include a User identifier in the 
	assertion to demonstrate interoperability.

	Security properties section has been changed to indicate only that
	service is available to messages with an assertion from a list of
	saml issuers.

Comments on Scenario 2 (sender-Vocuhes signed):

   (v2: 289)
1. line 274: I would prefer that the certificate be referenced from the msg
as apposed 
to being included in it.

	OK, I will use an X509SubjectName to refer to the key.

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?

	Agreed, user name list is not required for basic interoperability.
	It has been removed.

3. D.1.2 IssuerName - List - perhaps this section should be removed

	This addresses the usage of the Issuer attribute of the assertion.
	There is a degenerate case where the Issuer attribute matches the
	Subject of the certificate, but that may not always be the case
	and it is not required by SAML. The purpose of the list is
	to provide valid issuer names, which may be independently
	mapped to certificate subjects if that is what the implementation
	An alternative is to require the Issuer attribute match the 
	subject of the certificate in which case the list would not
	be needed, but this seems to me an unnecessary restriction.

4. D.1.4 Requester Cert Value - IMO, the SSL qualification should be

	Agreed, this was a typo.

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

	Plain text - again it is for emphasis, will leave in unless strong 

	As indicated in 1 above, a ref is now being used.

	I am assuming we want the certificate to be validated, although it
	up to the Responder how to implement this and there are no
	except that operationally it is in the Responder's interest to do
	However, it would seem to make sense that the Responder have a key
	where they can find the cert based on X509SubjectName.

	As in all the scenarios a diagram has been added to clarify the
	and their roles in the scenario to help understand the context of
	request and what the Responder needs to be looking for.

	I am calling the certificate the "Requester's certificate" to
	that it is the Requester doing the signing, in contrast to the hk
	where the Assertion Issuer is doing the signing.

                 (v2: 325)
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.

	As above, timestamp is for consistency with other ws-interop specs.

	As above, Conditions are going to be included to protect issuer
	against issuing unlimited assertions.

	As above, cert is now being ref'd so bst and str removed from table,
	text, and sample msg.

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

	I followed the SAML Token Profile V7 on this one, where the example
	in section does not use an STR. If the SAML Profile doc 
	is going to be updated along these lines, then I would agree that
	we should use it so that we can be consistent, perhaps by adding
	a new use case that demonstrates this capability.

   (v2: 350)
8. Line 335 KeyInfo: same comment, I would prefer that we not include the
but simply include its identifier.

	OK, that has been changed.

9. line 343: same comment about requiring an AuthenticationStatement. This
seems to 

	As above this has been changed to be any valid SubjectStatement.

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

	OK, the diagram that has been included identifies 2 actors: the 
	Requester and the Assertion Issuer. In general they can be 
	different entities, but they also can be the same entity.

	However, in order to keep the focus on the SAML assertion, the 
	scenario is requiring that both the Requester cert be validated
	and the Assertion Issuer be validated if they are different.

	Also, I agree that from a trust perspective, that it is the signer
	of the assertion + msg who is the real trusted party, but from a
	a pure SAML perspective the SubjectConfirmationMethod is used
	to validate the Subject of the assertion not the issuer of the 
	assertion. Therefore, I think it makes sense that the Responder
	validate the Issuer and whatever relation exists between the 
	assertion issuer and the requester is up to the responder to
	work out in the context of the preliminary agreements.

Comments on Scenario 3 (holder of key):

   (v2: 492)
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
within it. I don't have the SAMl spec at hand, but if we are going to say
we need to make sure cert containment is supported by SAML subject

	The SAML spec specifies that a ds:KeyInfo element can be used
	to specify the user key. This is from the dsig spec and allows
	a wide variety of options including the ds:X509Certificate.

	In general, the assertion issuer and signer must have the
	user key to include in the assertion. Otherwise, there must
	be some keystore that can be referenced by the ultimate
	recipient of the assertion. Since the issuer has no knowledge
	where the assertion might be going, it seems prudent to 
	make the assertion as self-contained as possible. Therefore,
	both the issuer certificate and subject certificate are
	included in the assertion.

2. Sections E.1.1 UserName-list  may be important to the methodology but it
just be a carry-over from the username password scenarios. I would recommend
or reducing the significance of the section (in this context).

	I agree that the username list is not needed for the trust
	mechanics of the interoperability. If the recipient trusts
	the assertion issuers signature then the recipient has a 
	basis to trust the signature that can be verified by the 
	user key contained in the assertion. This should be reflected
	in the updated scenario and diagram.
   (v2: 505)
3. Line 503: Requestor cert value - we need to provide the cert, but its
is accomplished within the subject confirmation element of the  assertions.

	This section has been modified to indicate that the Assertion Issuer
	certificate is the one the Responder must be prepared to validate,
	and that the User certicate is contained in the assertion. The 
	"requester certificate" is not an entity in this scenario any
	longer except where the requester and user are the same entity.

   (v2: 521)
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
on the msg (including cert validation) and thus establish the subject(s)
with the invocation.

	I have revised the text to explicitly say the order is not
	required, although all steps are necessary in any order. Also,
	I have removed the dependency on the user being identified.

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

	Same as response above: trying to maintain consistency with other
	interop specs on timestamp, and trying to use essential validation
	features of validity duration on assertion except in the minimal
	scenario 1.

6. IMO, requring authentication statements with holder-of-key is difficult
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.

	As in the other scenarios above, I agree that authentication
	are not required and they have been replaced with any subject
	although authentication statements have been left in the examples,
	is also consistent with the profile v7 spec.

7. line 604: I think the value of the issuer attribute within the assertion
always match the cert used to verify the assertion signature.

	I agree with you in principle, but the SAML spec says nothing to
	that and an issuer may not want to have their Issuer attribute be
	same text as that of the Subject of the certificate. This is the
	that an issuer list is needed as a basis for establishing that
	when it must be made.

	Also, trust is based on the issuer certificate, not on the Issuer
	although there may be policy requirement that the issuer attribute
	a particular value. i.e. the chain of trust flows thru the
signatures and
	the Issuer attribute may be used to distinguish different entities
	under the same parent - ex. Issuer="XYZ-Marketing",
	whereas the enterprise cert may simply be Subject="XYZ".


>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]