You can obviate the complexity of sections 7.3 and 7.5 only if section 7.7 is mandatory (with a 'MUST' wording), which means you force every middleware to implement immediately the 3 types of Authorization tokens.

In fact, you can NOT force that. This is the reason why I used the 'SHOULD' wording in section 7.7, and this forces the Information System to provide the list of Authorization tokens and transport methods really accepted by each grid Service.

I strongly disagree; PGI does need to force that. The goal is not to demand that *all* middleware endpoints be fully interoperable; just those that are advertised outside of that infrastructure. And if a particular endpoint is PGI-compliant, there is no reason it shouldn't be able to accept the two major credentialing mechanisms (SAML, AC), particularly since we're defining them to be equivalent.

What you propose does NOT foster interoperability:

If a client wishes to call a remote service, it must somehow translate its credentials into that service's desired format. This is what must be done at present time, and it's not interoperable.
Some types of credential-translation are simply not possible (e.g., converting a proxy-cert into an EEC), so whole classes of clients will be unable to use whole classes of services, which is not interoperable. We should avoid enabling this situation (because it's what we have at present time, so nothing is gained).

It's not that hard to support both credential mechanisms in the message-processing stack. In fact, it's harder to do what you propose: build the logic to detect service-type, perform token exchange, failover if service-type is unsupported, etc., into clients. And you gain virtually NOTHING for the effort.

The quickest route to interop is one in which

Inter-grid clients adhere to one (or more) of two profiles: SAML & AC (the idealized-Unicore is a sub-instance of idealized-Genesis II)
Inter-grid services support both, since we've defined the two client profiles to be semantically equivalent.

-Duane