Re: [wss] What constitutes a claim

[Anthony Nadalin <drsecure@us.ibm.com>]

Jerry,

I don't understand what you are getting at here, is there a specific issue
or just shooting the breeze ?

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122


|---------+---------------------------->
|         |           Jerry Schwarz    |
|         |           <jerry.schwarz@or|
|         |           acle.com>        |
|         |                            |
|         |           03/26/2003 05:57 |
|         |           PM               |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                              |
  |       To:       wss@lists.oasis-open.org                                                                                                     |
  |       cc:                                                                                                                                    |
  |       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 work
"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".

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. 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.  While this is possible, it seems an
awkward agreement. The most natural thing is to specify this with a usage
attribute of an STR that references this certificate.

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.

C. That Joe is an employee of Widget might reasonably be carried as a claim

in Joe's certificate.

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

E. This might be carried as a SAML security token.

F. This is essentially the same as D except the usage attribute would
presumably be different.

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