RE: [wss] What constitutes a claim

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

Thanks for your attention.

> [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.

Yes, this is the crux.  What then is the criteria for whether
something is a "security token".  The only definition in
the spec is

A security token represents a collection (one or more) of claims.

If something can represent a collection of claims, but yet not be a
security token, then we need to say that explicitly.

I have added a few more comments in blue, in line
below.

At 04:41 PM 3/26/2003, DeMartini, Thomas wrote:
> 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.

But they are exactly the kinds of claims that need
to be made about messages. If we aren't providing a mechanism to make
such claims then we aren't doing our job.  

> 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.)

Actually what I had in mind was that the computer
would encrypt parts of the message. But the principal is the
same.


> 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).


It seems unnatural to me too, but it was done when
we put the usage attribute into the STR. Possibly the people who voted
for that alternative weren't thinking of this as a place to make a claim,
but that's what it looks like to me.  In my example there are two
times associated with the message. The time at which Joe authorized it,
and the time at which it was sent. I propose to use the usage attribute
of an STR to distinguish the two. How do you propose to do it?

>  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?

Yes we can.  But I'm still unhappy because I
have no way of looking at a <Security> header and determining if
some elements assert claims. 

For example, suppose I have a web service that is completely open. That
is it does not require any encryption, or signatures, or
authorization.

   <wsse:Security>
<wsse:UsernameToken> 
      <wsse:Username> Jerry
</Username> 
   </UsernameToken> </Security>

The application can just ignore this, but does the <UsernameToken>
actually make a claim?  Does it matter? I think the answer to both
questions is no.