Re: encoding type of keyIdentifiers Issue 290 (proposal)

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

changed subject to include issue number

Ron Monzillo wrote:

> 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
>