[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 66: Security Policy Usecases
Is the use case document going to be an officially published doucment to the user community? I thought it was just going to be an internal document to make sure the ws-sp spec was complete.
Tony From: Rich Levinson [mailto:rich.levinson@oracle.com] Sent: Tue 10/17/2006 5:02 PM To: Anthony Nadalin Cc: Ashok Malhotra; Prateek.Mishra@oracle.com; ws-sx@lists.oasis-open.org Subject: Re: [ws-sx] Issue 66: Security Policy Usecases Hi Tony, I apologize for taking so long getting back on this - have been tending to other business responsibilities. I think I understand that you are interpreting what I would call the "explanation" as to what the meaning of the hk assertion is, as "processing requirements". That is not the intent. The assumption is that the client knows how to prepare a WS-Security header in compliance with the WS-Security profiles, and the only objective here has been to somehow use the ws-sp constructs to indicate the saml confirmation method (hk, sv, or bearer) so the client knows which type of profile to use. So, the explanatory text can be regarded as primarily to explain to the reader what is going on from a trust perspective. I think I could do another pass at the text in these to make that more clear, if that is what the committee chooses. Also, regarding issue 101, which has driven some of this analysis, after considering all the feedback, it is seems possible to me that the ws spec could be left unchanged, and that the use cases document, by example, could indicate implicitly which saml confirmation method the client would be expected to use. This would be non-normative and the user community at large could decide if it was sufficient or if another approach would be preferred. As it stands now, I think there still exists a gap between the explicit SamlToken specification in ws-sp and mapping that to the wss profiles as has been discussed. However, as a result of the analysis over the last several weeks, at least one approach has surfaced (generally suggested by Martin and reflected in the current version of the use cases / examples doc), which can close this gap with the spec as it currently exists, although, that approach does require some explanation, because it would not obvious to most people who have not actually been involved. That explanation does not need to be in the ws-sp spec as issue 101 currently requests. I believe the current use cases/examples doc can be modified so that we can simply assume if the saml token is in a ws-sp binding element that it should contain contain key material and therefore be a Saml hk token, and that at this point we can leave other saml tokens that are identified outside the binding element to be any kind of saml token. Whether to distinguish between sv and bearer as signed vs unsigned can be left as a TBD. Thanks, Rich Anthony Nadalin wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]