Apparent problems with SAML Assertion wsse:KeyIdentifier references in web service provider SOAP response

The CXF team has been attempting[1] to get CXF's stsclient to be able to access a Metro STS and subsequently make a SOAP call to a Metro WSP. The STS portion is fine, there are some issues with the subsequent SOAP call to the WSP however, some of which we fixed in the WSS4J security library that CXF uses. The CXF team believes there may be a couple of issues with the Metro WSP SOAP responses when SAML assertions are used as the credential, namely:

(1) For SOAP responses that do **not** include the actual SAML assertion, the wsse:KeyIdentifier nonetheless uses the reference ("#") symbol to identify the SAML assertion, for example ("#uuid-... below):

#uuid-526391a2-929e-49db-b890-54812517062b

The WSS4J team thinks the reference symbol should **not** be used if the element being referred to is **not** in the SOAP message, i.e., it should just be uuid-526391... without the leading #--otherwise implementations would be on a wild goose chase looking for resolutions to references that don't exist. Would the Metro team be in agreement with that?

(2) On Page 10, last paragraph in Web Services Security: SAML Token Profile 1.1 (1 February 2006) located here:
[http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf](http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf), lines 348-354 say the following:

"When a key identifier is used to reference a V1.1 SAML assertion that is not contained in the same
message as the key identifier, a element MUST be contained in the
element containing the key identifier. The contents of the
element MUST contain values sufficient for the intended recipients of
the to acquire the identified assertion from the intended
Authority. To this end, the value of the AuthorityKind attribute of the
element MUST be "samlp:AssertionIdReference"."

But no element is present in the Metro WSP's SOAP response back to the client, even though the SAML assertion is not in the message. Is there a reason for this omission, or am I misinterpreting the spec?

Probably unnecessary to answer the above two questions, but the full CXF client to Metro STS and CXF client to Metro WSP calls are here[2]. The Metro web service used is located here [3].

Thanks,
Glen

[1] [https://issues.apache.org/jira/browse/WSS-238](https://issues.apache.org/jira/browse/WSS-238)
[2] [https://issues.apache.org/jira/secure/attachment/12459880/WSS-238Results.txt](https://issues.apache.org/jira/secure/attachment/12459880/WSS-238Results.txt)
[3] [http://people.apache.org/~gmazza/20101117DoubleItMetroWSTrust.zip](http://people.apache.org/~gmazza/20101117DoubleItMetroWSTrust.zip)
#### Environment
Ubuntu Linux 64bit JDK 6.0
#### Affected Versions
[2.1]

Source: [https://github.com/javaee/metro-wsit/issues/1490](https://github.com/javaee/metro-wsit/issues/1490)
Author: glassfishrobot

Start by reviewing the Metro WSP SOAP response examples in the issue and the linked WSS-238 materials, then compare the KeyIdentifier and AuthorityBinding behavior with the referenced SAML Token Profile specification. Done means determining whether the response is non-compliant and identifying the Metro component or test coverage that would need correction.

Written by the indexing model from the issue text.