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


Hi Tony,

Thanks for the comments.

I do not believe that these use cases deal with processing assumptions, 
so much
as they demonstrate the wire format of what an initiator would expect to 
use if
these particular policy alternatives were what was supported and required by
the recipient.

In particular, there are 3 distinct types of Saml Assertion tokens  (hk, 
sv, bearer) that
are generally used in different appl contexts. In addition, there are 3 
distinct transports
that these SamlTokens may be used in, similar to X509 tokens.

The purpose of these examples is to show the initiator what the ws-sp 
policy looks like
for the different combinations of Saml token type and binding (each of 
which has its own
specific ws-sp structure, not simply picking a token type and all else 
is the same). In
addition, many of the examples relate to distinct WS-Security Saml Token 
Profile use
cases that have been interop'd in the past and that I believe 
implementors would want
to see how manifested in ws-sp.

I agree, as indicated in the meeting, that as Marc recommended in his 
email comments,
that the intros to each section need to be beefed up with motivating text.

Finally, I am not sure if you are saying that example 2.3.1.3 involves 
processing assumptions,
but, if that is the case, please explain a little further, since I think 
that has no more
processing assumptions than a similar example such as the ws-sp in the 
latest version
of scenario 1 of the latest interop doc distributed yesterday.

    Thanks,
    Rich

Anthony Nadalin wrote:
>
> 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
>


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