encoding type of keyIdentifiers

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Excerpt form minutes of "Draft Minutes of June 15 WSS TC meeting"

> Ron: There are some issues that reflect on core document. Value type 
> for encoding. In SAML profile Value type is string encoded. Core 
> requires base64 encoding. Incompatibility there. Core doesn't offer 
> enough options. Would prefer not to change the SAML profile. This 
> refers to the KeyIdentifier inside a security token reference.
> Hal: Inconsistencies between X509 token profile and mandates of core 
> spec. Unambiguous reference to a token. If we are looking at revisions 
> to SAML profile then we should reconsider X509 profile too.
> ACTION: Open a new issue to handle this. 


Proposed change to Core - change the following:

757: /wsse:SecurityTokenReference/wsse:KeyIdentifier/@EncodingType
758: The optional EncodingType attribute is used to indicate, using a 
URI, the encoding
759: format of the KeyIdentifier (#Base64Binary). The base values 
defined in this
760: specification are used (Note that URI fragments are relative to 
this document's URI):

to:

757: /wsse:SecurityTokenReference/wsse:KeyIdentifier/@EncodingType
758: The optional EncodingType attribute is used to indicate, using a 
URI, the encoding
759: format of the KeyIdentifier. This specification defines the 
EncodingType URI values
appearing in the following table. Additional token specific EncodingType 
URI values
and token specific default EncodingType URI values MAY be defined by the
token specific profiles.

One of the issues already identified to be addressed in the errata to 
the core, is
correction of the ambiguous use of fragment URI values. I did not try to 
correct
the #Base64Binary fragment identifier, as I figured that is already 
something that should
be done. IMO, the table should be made explicit; that is we should drop 
thsi editorial shorthand.

Ron