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
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
"Ashok Malhotra" <ashok.malhotra@oracle.com>
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