RE: [wss] What constitutes a claim

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

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?