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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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

Ashok, thanks for reminding me. So for example take 2.3.1.3, it states "Initiator may be considered to be authorized by the issuer of the hk SAML assertion to bind message content to the Subject of the assertion. If the Client Certificate matches the certificate identified in the hk assertion, the initiator may be regarded as executing SAML hk responsibility of binding the Subject of the hk assertion to the content of the message." this implies processing assumptions that can't be addressed in WS-SecurityPolicy.


Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Ashok Malhotra" <ashok.malhotra@oracle.com>"Ashok Malhotra" <ashok.malhotra@oracle.com>



To

Anthony Nadalin/Austin/IBM@IBMUS

cc

"Prateek.Mishra@oracle.com" <Prateek.Mishra@oracle.com>, "Rich Levinson" <rich.levinson@oracle.com>, "ws-sx@lists.oasis-open.org" <ws-sx@lists.oasis-open.org>

Subject

RE: [ws-sx] Issue 66: Security Policy Usecases

Hi Tony:
On last week's WS-SX call we said that we did not understand what you meant by
"processing assumptions" on some of the usecases. See your note below.
You offered to clarify. Could you please send the clarifications. We are anxious to
make progress on the usecase document.

All the best, Ashok




From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent:
Wednesday, September 27, 2006 6:53 AM
To:
ws-sx@lists.oasis-open.org
Subject:
[ws-sx] Issue 66: Security Policy Usecases

While reading the document quite a few of these use cases were confusing as they had to deal with processing assumptions rather than wire format assumptions. So while we can think up many usecases, I'm not sure the purpose of several of the scenarios in section 2.3 (like 2.3.1.3)

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

GIF image

GIF image



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