[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] What constitutes a claim
Jerry and Thomas, Thanks for taking the time to work through this. I have not dug into all the details, but as I understand the discussion, it seems that like there is some agreement that making a claim is not a sufficient property of a thing for it to be called a security token. I forgot what the counter argument was, but it seems to me that we have defined a necessary property of things that we designate as security tokens by type; that they must be referenceable by an STR. AFAIK, this is the only type specific, distinguishing feature of the use of the term security token in the wss specs. IMV, a type cannot be an ST unless it is referenceable by an STR. This may not turn out to be much of a distinguishing characteristic, since pretty much every xml type is referenceable by an STR, and we do not specify that an instance of a type is only an ST when it is being referenced (by an STR). I would think that anything that is being referenced by an STR is an ST, but there would seem to be ambiguity in the space of things that occur in a security header and that are not being referenced by an STR. Perhaps we just need to define if and when unreferenced things in a security header are to be considered security tokens. IMV the determination of whether or not something in (or referenced from) a soap msg is a security token is more a matter of its use (WRT to the processing of the msg) than its type. Another comment on the discussion - which rasised a concern about the usage attribute of an STR being ised to carry additional claims. When an STR is used within keyinfo, doesn't it get digested and signed with the rest of the signed data? If this is the case, the STR can be used by the signer to securely attach claims (in addition to the signer's identity) to the signed data. Ron Jerry Schwarz wrote: > At 06:23 PM 3/26/2003, Anthony Nadalin wrote: > > > > >> Jerry, >> >> I don't understand what you are getting at here, is there a specific >> issue >> or just shooting the breeze ? > > > This is continuing discussion on the meaning of "security token" which > I began on the conference call. It's making the same point (that > "security token is not well defined) that I've been trying to make > many times. Call it "shooting the breeze" if you like but it is > definitely related to the content of the spec and I think appropriate > for this list. > > >> 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". > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]