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


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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

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

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.


To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC