I’ve also published a post on my blog with some problems and ideas about the policy chain discovery problem: http://www.cc.isel.ipl.pt/CS/blogs/pfelix/archive/2007/06/04/notes-on-the-policy-chain-discovery-problem.aspx
Any comments on this post would be highly appreciated.

Thanks for clarifying your questions. It appears I understood your intention and answered correctly.

Regarding your revised question 3, I agree there is some overlap between Federation Metadata and WS-SecurityPolicy with respect to an RP’s requirements. We discussed this while writing the spec and concluded that metadata, such as “TokenIssuerEndpoint” is not completely redundant, as I stated in my original response. We have learned from customer experience that many RPs and IPs participate in different federations concurrently. The Federation Metadata document can be sectioned to facilitate publishing the RP requirements, as well as the IP capabilities, that are unique to a particular federation.

Regarding your question 5, the chain if IPs you describe is one of the reasons why publishing an IP’s capabilities is usefl to InfoCard clients. As you implied, the act of provisioning an InfoCard client by managed-card providers will “train” the client with respect to that IP’s capabilities. Since a chain of managed-card providers is not supported in some first generation clients, the correct chain of subsequent IPs can be discovered using WS-MetadataExchange to retrieve WS-SecurityPolicy and Federation Metadata documents.

Further, we are still working through the client provisioning and update process for managed-card providers. Publishing an IP’s capabilities may play a role here as well.

1) Why does the requester needs the federation metadata, except for the “SingleSignOutElement”? Isn’t all the other information needed by the requester present in the service’s policy, namely the token issuer endpoint and the required claims (contained inside a policy assertion)?

2) Who are the consumers of the federation metadata exposed by the RP? Is it only the requester? Is it the IP? Can’t the “TokenIssuerEndpoint” information be stated inside the “Issuer” element on the “IssuedToken” assertion? The same applies to the “TokenKeyTransferKeyInfo”.

Regarding your comments:

1) I understand and agree that an IP can also have the RP role: it will be the producer of tokens but also the consumer. When I refer to an RP it does not have to be the final RP in the chain, it just a token consumer.

2) I also understand that the WS-SecurityPolicy assertions do not provide a way to express capabilities. However, I think that the policy is the right place to express capabilities. So, shouldn’t the WS-SecurityPolicy be extended with this information (e.g “SingleSignoutNotificationEndpoint”)?

3) I agree with you that the “SingleSignoutNotificationEndpoint” capability exposed by RPs is useful to requesters. But I also think that it is the only federation metadata information exposed by a RP that is relevant to the requester. For example, the “TokenIssuerEndpoint” is completely redundant, since it is in the RP’s policy.

4) The “TokenKeyTransferKeyInfo” can be useful if the IP wishes to provision the RP key during the federation setup. However, this key can also be present in the “AppliesTo” element present in the RP policy and inserted in the RST message sent to the IP.

5) Regarding the discovery of IPs by a requestor, I think that this does not solve the problem completely. First, using “information cards” (IC), the requester already knows what are the claims and token types exposed by some IPs. This information would be useful for intermediary IPs (IPs that receive tokens from IPs and issue tokens to other IPs or RPs). For example, this could enable “bidireccional” construction of policy chains: construction of policy chains starting at both the requestor and the final RP and running both ways until a complete chain is established. However, for this to be possible, the IPs would have to expose the capabilities of other IPs.
I would like to discuss this subject further; however this comment is getting rather long.

Once again, thanks for your reply and sorry for the long comment.

There seem to be some words that got dropped in your comments. I will do my best to fill in the blanks and answer your questions.

First, it is useful to point out that there is not always a complete separation between the IP and RP service provider roles. For example, an IP is temporarily in the Relying Party role when it receives a request to issue a token and it must authenticate the requestor.

Second, WS-SecurityPolicy allows service providers, both IPs and RPs, to publish their requirements. However, WS-SecurityPolicy does not provide a mechanism for them to publish their capabilities. One of the goals of federation metadata is to allow service providers to publish their capabilitiies.

fed:TokenTypesOffered and fed:URINamedClaimTypesOffered are examples of “capability” metatdata statements. Your observation is correct that they are useful for IPs rather than RPs. However, there are “requirement” metadata statements that are useful for RPs (or IPs when they are the Relying Party role). fed:TokenKeyTransferKeyInfo and fed:SingleSignoutNotificationEndpoint are examples.

One use case for federatin metadata enables federation partners, IPs and RPs, to automate their configurations [about each other]. We wanted to address this because customers have complained about the manual mechanism for configuring federation partners in ADFSv1 and other first generation WS-Federation products. Automating this configuration process can be facilitated if IPs publish capability statements (e.g. fed:TokenSigningKeyInfo and fed:SingleSignoutSubscriptionEnpoint) and RPs publish requirement statements (e.g. fed:TokenKeyTransferKeyInfo and fed:SingleSignoutNotificationEndpoint).

Another use case involves automating the ability of requestors — especially InfoCard style clients, such as, CardSpace — to determine which IPs can satisfy RP requirements. RPs can express their token type and claim type requirements in WS-SecurityPolicy. If RPs do not specify specific IPs for issuing tokens, clients must match up IPs and RPs based on token and claim types. This requires that IPs publish their capabilities using metadata statements (e.g. fed:TokenTypesOffered and fed:URINamedClaimTypesOffered) since their is no mechanism for them to do this in WS-SecurityPolicy.

There is some overlap between WS-Federation metadata statements and WS-SecurityPolicy assertions. fed:TokenIssuerName and fed:TokenIssuerEndpoint correspond to sp:IssuerName and sp:Issuer, respectively. However, the WS-Federation metatdata statements can be repeated in separate sections of the metadata document (as specified by FederationID) to indicate different IPs that are trusted in different federations in which the RP participates.

I can understand the importance of the federation metadata exposed by the IPs, but not the metadata exposed by the RP.