RE: [wss] What is a "Security Token"

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

At 03:06 PM 2/21/2003, Hal Lockhart wrote:
> I
> agree that the current spec is broken. I suspect we need two collective
> terms: one for all the different kinds of elements that can go in a
> Security Header and one for things that contain claims.
>  
> However, I think you are
> misinterpreting the idea of a claim. Saying "Joe is an Admin"
> or "this is the public key of an authorized purchaing agent of
> GM" are claims. 

Certainly these are claims, but in the context of a SOAP message they are
relatively uninteresting unless there is an additional claim that Joe or
the the authorized purchasing agent has some relationship to the
message.

> These
> are gathered into Tokens and signed by an Authority that asserts them to
> be facts. 

My reading would be that "Authority asserts ... ". Where the
ellipsis are the claims of the signed element. It is the signature itself
that carries that claim.    

>  
> What the signature does is not
> make a claim, but bind the claim to a message allowing us to verify that
> the claims apply to the orginator of some
> message.

I don't understand the phrase "bind the claim to a
message".  

I'll assume by "message" you mean whatever part of the SOAP
message has been signed. As I understand the word "bind" it
means something like "fill in a part of a phrase", or
"specify the referent of a reference". It only makes sense to
talk about binding to something with a gap to be filled in. The SOAP Body
(say) doesn't have a gap to fill.  What would have a gap to be
filled in is an assertion like "the signer is the originator of the
body" with the entity that did the signing.

So as I see it the claim is "Joe originated the 
body".

All the above relates to signatures where it is reasonable to talk about
claims. The situation is even murkier when we look at
encryption.

>  I
> think this is a reasonable distinction which we should preserve, but I
> agree it would be useful to have a term that encompasses the
> superset.

The distinction I think is important is between the elements (such as
signatures and encryptions and SecurityTokenReferences) whose meaning we
define, and the "security tokens" that might or might not carry
claims themselves.  Nothing in the core document depends on whether
they do.

 
Hal

-----Original Message-----

From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]

Sent: Thursday, February 20, 2003 9:21 PM

To: wss@lists.oasis-open.org

Subject: [wss] What is a "Security Token"

This note discusses the use of the phrase "Security Token" within the core document. I have found it confusing and propose eliminating it.

The current draft (and I believe all earlier ones) defines "Security Token" as[209]

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

And defines a claim as [188]

   "A claim is a declaration made by an entity"

This language is confusing within the context of signatures.  Section 8 [741] says "An XML Digital Signature can be used to bind a claim ...." which suggests, although it doesn't come out and say it, that the signature is not itself a claim

Consider this in the context of example 2.4 [274] which contains a <wsse:UserName> element and a signature.  The <UserName> element does not contain a digest.  The commentary says [274] "the username token containing a claimed security identity".  But an identity is not a declaration.  The claim in the example is carried by the signature.  It is something like

The entity identified in the <UserName> element has made a request for the stock information contained in the SOAP body.

I believe that the important concept is direct subelement of a <Security> element and that the semantics of that element should not be assumed to be a security token.  I propose to call this a "security information element", or S-element for short and to replace "security token" with the phrase throughout the document.

If this is agreed to I'll propose detailed edits.