[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Rationalization of Usage rules for <Issuer> in profiles?
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]