RE: [security-services] Rationalization of Usage rules for <Issuer> in profiles?

["Scott Cantor" <cantor.2@osu.edu>]

> There may well be reasons for the variations but I've 
> identified three categories of rules for the <Issuer> element 
> with the various 'Usage" sections within the profiles doc. 
> The different protocol messages are listed below along with 
> their corresponding rule for <Issue>.

I had reasons, but I'll let others decide if they're reasonable...

> <AuthnRequest>, <NameIDMappingResponse>, 
> <ManageNameIDRequest>, <ManageNameIDResponse>
> <ArtifactResolve>, <Response> to Query/Request, <ArtifactResponse>
> 
> The <Issuer> element MUST be present and MUST contain the 
> unique identifier of the artifact issuer/requesting 
> entity/responding entity; the Format attribute MUST be
> omitted or have a value of 
> urn:oasis:names:tc:SAML:2.0:nameidformat:entity.

Right, I moved the rules for this to profiles so that it was clearer that in
these profiles, the requester and responder are system entities in the
SP/IdP sense. Other profiles might build on these protocols for some other
use case.

> ----------------------------------------------------
> 
> <NameIDMappingRequest> , Query/Request
> 
> The <Issuer> element MUST be present.

Here, there is no requirement that the requester be anything in particular.
It could be a principal, even. These protocol profiles are more generic in
nature.

> ----------------------------------------------------
> 
> <Response> to <AuthnRequest>
> 
> The <Issuer> element MAY be omitted, but if present it MUST 
> contain the unique identifier of the issuing identity 
> provider; the Format attribute MUST be omitted or have a 
> value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity

This one is simply an issue of saving space given that the response won't be
signed, generally. Having moved the signature to the assertion, the protocol
wrapper becomes dead weight, but some of us are layering freaks, I guess.

Anyway, it may be that saving space doesn't outweigh creating strange
exceptions to processing rules that might create interop problems. Every MAY
or SHOULD is another place for implementers to get confused.

-- Scott