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: [wss] Binding Specification Templates


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.



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


Powered by eList eXpress LLC