Re: [wss] Binding Specification Templates

I think this illustrates a generic problem with the way the use of
security tokens is described.  Section 3.1 says that security tokens
assert claims, but in the various profiles there aren't explicitly pulled
out statements of the claims. 

Consider the simplest case which is section 6.1 where the UserNameToken
element is described. The closest it comes to a claim is line 423. 

The <wsse:UsernameToken> element is introduced as a way of
proving a username and optional password information.

This doesn't parse as a claim to me.

I think there are two claims here. One is that the request is from a
principal identified by the username, and the other is that the principal
knows the password. This shows a missing gap because there is no way to
distinguish an ultimate client from an agent or intermediary.  

At 11:03 AM 11/05/2002, DeMartini, Thomas wrote:

Colleagues,

It seems that for certain bindings of WSS (SAML and XrML in particular)
there may be a more straight-forward way of describing processing
rules.  Currently, the bindings for these have processing rules
described under "proof-of-possession" (in other words, you
start with the token and then try to figure out if there is proof of
possession, without even knowing if you need to do that for the purposes
of that message).

Recall that SAML and XrML express, among other things, things like
"A can do B upon C."  A statement such as "A can do B
upon C" doesn't have any inherent processing rules that need to be
associated to it necessarily.  A better way might be to look at the
message.  For instance, if the message is encrypted, we only need an
identification of the key that can decrypt it, not a statement like
"A can do B upon C."  If the message is signed using a key
(say k), we need to validate the signature (say it succeeds), check the
semantics of the message (say that it is that Alice is requesting two
tickets (to see a movie)), check that the request is fresh (say that it
is), check that Alice is authenticated to k (say that she is), check that
"Alice can request upon tickets" (say that she can), and,
finally, process the request and generate the response.  (Also, as
Phill pointed out in his recent e-mail, we ought to also indicate where
the callers should put -- and the receivers expect to find -- the tokens
for each of these steps in order to avoid the cost of figuring out the
chains on the server side.)

In this way, it is clear what the intent and processing rules of the
token are, once we establish that there is first some processing to
determine what it is we are trying to prove with the tokens based on the
message coming in.  I think this is clearer rather than just looking
at the tokens and explaining some of the things we can prove with
them.

Thanks,

Thomas.

----------------------------------------------------------------

To subscribe or unsubscribe from this elist use the subscription

manager:
<http://lists.oasis-open.org/ob/adm.pl>