[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] What constitutes a claim
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. 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: 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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]