Re: [wss] Binding Specification Templates

[Jerry Schwarz <jerry.schwarz@oracle.com>]

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>