RE: [wss] What constitutes a claim

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

This is exactly the kind of discussion I was trying to stimulate.

At 04:57 PM 3/26/2003, DeMartini, Thomas wrote:
>While we are on the subject, it might make sense to compare and contrast
>the UsernameToken ST with other STs.
>
>For other STs (such as X.509), we have another specification (such as
>the X.509 specification) we reference to make it clear what claims are
>made by the token.  For the UsernameToken, we do not have this luxury
>and should make it clear when we define the UsernameToken.
>
>I propose the following:
>A. If a UsernameToken contains a Username element, the UsernameToken is
>making the claim that that user created the message.

This would seem to imply that a <Security> element could contain at most 
one <UsernameToken>.  This would seem to be overly restrictive to me. We 
may want to identify more than two actors.  And it would preclude me from 
using the <UsernameToken> in various reasonable ways.

For example, a web service receives a message with a <UsernameToken>. In 
order to do its job it wants to make a request of another web service. It 
isn't forwarding the original request, but creating an entirely new 
request. Your formulation seems to preclude it from passing on the 
<UsernameToken>. That seems to be a gratuitous restriction.

Also you'll just stimulate philosophical debates about what "creating a 
message" means.

>B. If a UsernameToken also contains a Password element, the
>UsernameToken is making the additional claim that that user has that
>password.
>C. If a UsernameToken also contains a timestamp/nonce, the UsernameToken
>is making the additional claim that the UsernameToken is only to be
>applied to one message.
>
>What follows is an explanation of why I think those are the appropriate
>claims for a UsernameToken to be making and some comparison/contrast to
>some other key-based security token types we have been dealing with.
>
>--
>
>Consider a generic hypothetical key-based token type.  Conceptually, we
>have four things in an example request:
>
>1. The hypothetical token which makes the claim that a particular key,
>K, belongs to "Thomas".
>2. The message body.
>3. The signature of the token signing authority over the token.
>4. The signature of K over the message, timestamp, and nonce.
>
>When the token signing authority signs the token, the token signing
>authority vouches for the claims the token makes (in this case, that the
>key belongs to "Thomas").
>
>When K signs the message, timestamp, and nonce, K is vouching for the
>message and the freshness of the message.
>
>--
>
>Now, consider the UsernameToken case without a password.  In this case,
>the user represented by the username cannot sign the message because he
>has no key (unless he uses his password to sign the message), so, to
>make it secure, we have a third party sign the message.  Conceptually,
>we have three things in an example request:

Or we could be in an environment where the service can determine a public 
key associated with the user simply by knowing the user's name.


>1. The UsernameToken which makes the claim that "Thomas" created the
>message.
>2. The message body.
>3. The signature of the token signing authority (third party) over the
>token, the message body, message timestamp, and message nonce.
>
>When the token signing authority signs the token, the token signing
>authority vouches for the claims the token makes (in this case, that
>"Thomas" created the message).  Because it is unwise to vouch for
>"'Thomas' created the message" without also ensuring the integrity of
>the message, the signing authority's signature includes the message
>body, message timestamp, and message nonce to vouch for the message and
>its freshness.
>
>--
>
>These UsernameToken semantics also hold in the non-secure case as well
>when we have no third party signature.  In this case, we simply have two
>things in an example (non-secure) request:
>
>1. The UsernameToken which makes the claim that "Thomas" created the
>message.
>2. The message body.
>
>--
>
>If the UsernameToken also contains claims about password (B) or
>freshness (C), it does not change either of the two UsernameToken
>scenarios above except that additional claims are made by the token.
>
>Thanks,
>Thomas.
>
>-----Original Message-----
>From: DeMartini, Thomas
>Sent: Wednesday, March 26, 2003 4:41 PM
>To: Jerry Schwarz; wss@lists.oasis-open.org
>Subject: RE: [wss] What constitutes a claim
>
>See my comments inline after [DeMartini, Thomas].
>
>Thanks,
>Thomas.
>
>-----Original Message-----
>From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
>Sent: Wednesday, March 26, 2003 3:58 PM
>To: wss@lists.oasis-open.org
>Subject: [wss] What constitutes a claim
>
>
>My idea of what constitutes a "claim" seems so straightforward to me
>that I
>have a hard time understanding what other definitions might be possible.
>
>Yet discussions with several members of the committee have convinced me
>that they have a different idea and in the interests of clearer
>communication I hope this email will lead to a better understanding.
>
>Since we don't have a formal language in which to express claims, I use
>English and propose below a number of English statements that I belive
>are
>the kinds of claims that would be related to SOAP messages.  I discuss
>how
>I believe those claims might be carried within a <Security> element
>below.
>
>A. The message was sent from a computer owned by Widget Inc.
>
>B. The request in the message was authorized by Joe
>
>C. Joe is an employee of Widget Inc.
>
>D. Joe authorized this request at 8AM on April 1, 2003.
>
>E. Sam vouches that Joe was a purchasing agent of Widget Inc on April 1,
>2003.
>
>F. This request was sent on May 1, 2003.
>
>If you think any of the above isn't a "claim" then you're using the word
>
>"claim" with a technical meaning rather than its plain English sense.
>If
>so, I'm curious to see what the definition is and there is a consensus
>on
>that definition then it should be added to clarify the meaning of
>"security
>token".
>[DeMartini, Thomas] I agree that all of the above are claims.
>Conceivably, we could have security tokens claiming any of them.
>However, we don't currently have security tokens that make all these
>claims (and we don't need security tokens that make all these claims).
>This is, I think, where the confusion lies: they are valid claims, but
>they are not the claims made by the security tokens we are dealing with.
>I will elaborate more on this below.
>
>A, B, D and F specifically refer to the message.  In the context of WSS
>that's what makes them interesting.  C and E which don't refer to the
>message are interesting because the are claims about entities refered to
>in E.
>
>Observe that the above claims mention four entities: The computer that
>sent
>the message, Joe, Sam and Widget Inc.  All these must somehow be
>referenced
>in the XML. Let's assume that these entities are all identified by X509
>certificates within <BinarySecurityToken> element. As people have
>repeatedly pointed out to me, X509 certificates carry claims. However,
>they
>can't carry A, B, D or F because those claims refer specifically to the
>message.
>
>Consider the claims in turn
>
>A. That the computer is owned by Widget Inc can reasonably be part of
>the
>X509 certificate.
>[DeMartini, Thomas] This is correct.
>
>The client and server might agree that any certificate
>(i.e. the <BinarySecurityToken> that contains the certificate) that is
>an
>immediate sub-element of the <Security> header is the certificate of the
>
>machine that is sending the message.
>[DeMartini, Thomas] I think it would be bad design if this were the
>case.
>
>While this is possible, it seems an
>awkward agreement.
>[DeMartini, Thomas] Agreed.
>
>The most natural thing is to specify this with a usage
>attribute of an STR that references this certificate.
>[DeMartini, Thomas] I think the more natural thing, actually, would be
>to have the computer sign the message.  It is the signature of the
>message that makes the additional claim that the sender of the message
>is the computer.  (NB: I am not implying the signature is a security
>token, only that security tokens are not the only things that may make
>claims.)
>
>B. That Joe authorized the request might be indicated by the fact that
>Joe's certificate was used to sign the body. To be more explicit about
>it
>the STR that references Joe's certificate could have a usage attribute.
>B
>seems to be the crux of the difference between myself and other members
>of
>the committee.  I've been told repeatedly that signature's aren't
>security
>tokens, from which I conclude that they don't make claims.  So either
>people have in mind some other way of carrying (B) or that don't think
>(B)
>is a claim.  I would like clarification.
>[DeMartini, Thomas] I think your analysis of the crux of the difference
>is correct.  I do not conclude that just because Signatures are not
>security tokens they may not carry Claims.
>
>C. That Joe is an employee of Widget might reasonably be carried as a
>claim
>in Joe's certificate.
>[DeMartini, Thomas] Yes.
>
>D. The time at which the request was made is carried in a <Timestamp>
>element.  There is no usage attribute in a <Timestamp>, and we need
>something to distinguish that the <Timestamp> is the authorization time
>and
>not the time at which the message was sent. On possibility is to treat
>the
><Timestamp> as an embedded "security token"  in an STR and add a usage
>attribute.  Note that in this context it is the STR itself that asserts
>the
>claim and the embedded "security token".
>[DeMartini, Thomas] I think it would be bad design if we had to embed
><Timestamp> in STR in order to indicate what its meaning is.  If the
>specification of the <Timestamp> element does not adequately indicate
>its semantics (either authorization or sent time) them we must fix the
>specification of the <Timestamp> element.  Perhaps it is simply the case
>that we do not have a security token to express one of the claims
>(either D or F).
>
>E. This might be carried as a SAML security token.
>[DeMartini, Thomas] Agreed.
>
>F. This is essentially the same as D except the usage attribute would
>presumably be different.
>[DeMartini, Thomas] Same comment as D.
>
>All this is hypothetical and there are many alternative ways to carry
>these
>claims. The discussion is intended to explore what kinds of elements
>might
>be used.  In particular note that signatures and STR's carry many of the
>
>claims in the above. If we want to exclude them from being allowed as
>embedded "security tokens" in STR's then we need to do so based
>explicity
>on the tag's of the elements and not based on whether or not they
>"assert a
>claim".
>[DeMartini, Thomas] I agree with the last sentence.  I think it would be
>highly undesirable for STRs to carry claims beyond those of the ST they
>reference (anything they provide should be a hint only).  I am fine with
>Signatures and Messages carrying claims.  In fact, if we were to decide
>that Signatures do not carry claims (which hopefully we don't), then we
>would have to redefine Claim in some more technical sense.
>I think, at this point, we can agree that we can require that security
>tokens assert claims, without requiring that all claims be asserted by
>security tokens?