The Liberty ID-WSF architecture appears to be a very different beast than the OGSA paradigm. (Clients use "discovery" services that locate desired provider services; the discovery services respond back with ID-WSF EPRs that wrap both the endpoint information and any necessary security credentials that client needs to provide for service authorization.) For a brief perspective on the Liberty ID-WSF architecture, I would recommend the following document sections:

Section 5 of the Liberty ID-WSF Architecture Overview (http://www.projectliberty.org/liberty/content/download/889/6243/file/liberty-idwsf-overview-v2.0.pdf)
Section 4 of the Liberty ID-WSF Security and Privacy Overview (http://www.projectliberty.org/liberty/content/download/327/2405/file/liberty-idwsf-security-privacy-overview-v1.0.pdf)

There are three specifications concerning their security architecture that I have found to be relevant to the discussions we've been entertaining:

Liberty ID-WSF Discovery Service Specification (LibertyDisco: http://www.projectliberty.org/liberty/content/download/875/6201/file/liberty-idwsf-disco-svc-v2.0.pdf)

Liberty ID-WSF Security Mechanisms Core (LibertySecMech: http://www.projectliberty.org/liberty/content/download/893/6255/file/liberty-idwsf-security-mechanisms-core-v2.0.pdf)
Liberty ID-WSF SOAP Binding Specification (LibertySOAPBinding: http://www.projectliberty.org/liberty/content/download/897/6267/file/liberty-idwsf-soap-binding-v2.0.pdf)

The LibertyDisco spec is perhaps the most interesting, as it draws from the other two to create a ID-WSF profile for EPRs. In their terminology, an ID-WSF EPR comprises the "invocation context" necessary for interacting with the targeted service instance. Within the EPR's <Metadata> document, they use <SecurityContext> element(s) to express a grouping of security-specific metadata regarding the service provider. In this regard, their <SecurityContext> EPR metatadata extension is similar to the OGSA BSP-Core's <EndpointKeyInfo> metadata extension.

A <SecurityContext> contains one or more <SecurityMechId> elements and zero or more <Token> elements. (See the example ID-WSF EPR in the postscript at the end of this email.) The <SecurityMechId> element (defined in LibertySecMech) contains a URI that identifies the peer (transport) and message authentication mechanisms required by the service provider. Examples are:

urn:liberty:security:2005-02:TLS:X509 (Server-authenticated TLS transport-level security with authentication of the client via the WS-S X.509 Token Profile at the SOAP level)
urn:liberty:security:2006-08:ClientTLS:SAMLV2 (Mutually-authenticated TLS transport-level security with authentication of the client via the WS-S SAML2 Token Profile at the SOAP level)
urn:liberty:security:2003-08:null:null (No transport-level security or message-level security)

There does not appear to be a mechanism for specifying if/what encryption needs to be done at the message level (as required by the service resource). They suggest that message-level encryption be used in the presence of intermediaries, but it would appear that doing so would be at the discretion of the client; there is no mechanism for making it a provider-requirement.

Unlike the OGSA BSP-Core, the <Token> elements with in a ID-WSF <SecurityContext> do not describe security tokens that are to be used expressely for authenticating the resource service to the client. Rather, they are either (a) authZ security tokens for the client to place in the outgoing message's SOAP WS-S security header or (b) a "target identity" to be placed in the outgoing message's ID-WSF SOAP header analogously to the way we use reference parameters.

Additionally, neither the LibertySecMech nor the LibertySOAPBinding documents specify any mechanism for indicating the security context required by the client for response messages.

In summary, I don't believe that the Liberty ID-WSF profiles on SOAP and WS-Addressing will provide us complete solutions for the considerations that I outlined in the recommendations document. Their <SecurityMechID> element is a good approach for advertising authentication mechanisms, but it lacks the ability to express the message-confidentiality requirements of the service resource. They do not profile the binding of key/cert material to EPRs for the purpose of authenticating the resource/endpoint to the client (let alone the intended usage for such key material). They do not profile a mechanism for indicating client requirements for response message-level security.

-Duane

PS -- The following is an example of an ID-WSF EPR taken from the LibertyDisco specification containing two alternative security contexts for interaction:

<wsa:EndpointReference
  notOnOrAfter="2005-08-15T23:18:56Z"
  ...>
<wsa:Address>
  http://profile-provider.com/profiles/so meFoobarProfileAddr
</wsa:Address>

<wsa:Metadata>
  <ds:Abstract>
   This is a personal profile containing common name information.
  </ds:Abstract>

<ds:ProviderID>http://profile-provider.com/</ds:Provi derID>

<ds:ServiceType>urn:liberty:id-sis-pp :2003-08</ds:ServiceType>

<sbf:Framework version="2.0" />

  <ds:SecurityContext>
   <ds:SecurityMechID>
    urn:liberty:security:2006-08:ClientTL S:SAMLV2
   </ds:SecurityMechID>

   <ds:SecurityMechID>
    urn:liberty:security:2005-02:Cli entTLS:SAML
   </ds:SecurityMechID>

<sec:Token wsu:id="_10"
     usage="urn:liberty:security:tokenusage:2006-08:Secu rityToken">
    
   </sec:Token>
  </ds:SecurityContext>

  <ds:SecurityContext >
   <ds:SecurityMechID>
    urn:liberty:security:2005-02:ClientTLS:X509
   </ds:SecurityMechID>

<sec:Token wsu:id="_20"
     usage="urn:liberty:security:tokenusage:20 06-08:InvocationIdentity">
    
   </sec:Token>
  </ds:SecurityContext>

  <ds:Options>
   <ds:Option>urn:liberty:id-sis-pp</ds:Option>
   <ds:Option>urn:liberty:id-sis-pp:cn</ds:Option>
   <ds:Option>urn:liberty:id-sis-pp:can</ds:Option>
   <ds:Option>urn:liberty:id-sis-pp:can:cn</ds:Op tion>
  </ds:Options>
</wsa:Metadata>

</wsa:EndpointReference>