OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposed text changes to 1.1 re: EncryptedKey references


Since STRs can now point to EncryptedKey elements, some adjustment of the language in the core spec seems to be required. It seems best to leave the definitions of Claim, Security Token and Signed Security Token alone* and fix the text in Chapter 7. 

Therefore I propose changing the text at the beginning of Chapter 7 (lines 660-670) from:

---------
7 Token References

This chapter discusses and defines mechanisms for referencing security tokens.

7.1 SecurityTokenReference Element

A security token conveys a set of claims. Sometimes these claims reside somewhere else and
need to be "pulled" by the receiving application. The <wsse:SecurityTokenReference>
element provides an extensible mechanism for referencing security tokens.

The <wsse:SecurityTokenReference> element provides an open content model for
referencing security tokens because not all tokens support a common reference pattern.
Similarly, some token formats have closed schemas and define their own reference mechanisms.
The open content model allows appropriate reference mechanisms to be used when referencing
corresponding token types.
----------

to:

==========
7 Token References

This chapter discusses and defines mechanisms for referencing security tokens and other key bearing elements.

7.1 SecurityTokenReference Element

Digital signature and encryption operations require that a key be specified.  For various reasons, the element containing the key in question may be located elsewhere in the message or completely outside the message. The <wsse:SecurityTokenReference> element provides an extensible mechanism for referencing security tokens and other key bearing elements.

The <wsse:SecurityTokenReference> element provides an open content model for referencing key bearing elements because not all of them support a common reference pattern. Similarly, some have closed schemas and define their own reference mechanisms. The open content model allows appropriate reference mechanisms to be used.
==========

BTW, it is not clear to me that it is ever useful to use an encrypted key for a signature, but I cannot say for sure so I am not proposing any changes around this point.

Also note in lines 858 and 868 EncryptedKey is spelled wrong. (Out of 12 occurances ;-)

Hal


* Note that there are still problems with these definitions. For example, the term security token apparently covers both an X.509 certificate and a BinarySecurityToken element containing an X.509 certificate. I believe the BSP has clarified that a STR pointing to a token located outside the message can be indicating the naked token.

Also the definition of Claim seems problematic as it is necessary for a token to associate at least two pieces of information with each other in order to have any utility (e.g. name and key, name and attribute) However this association may be implicit, for example a SAML bearer token could just contain subject name in whihc case the implicit association is that the named subject sent the current message. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]