OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: comparing the X.509 deployment profiles

It is instructive to compare the following pair of X.509 deployment profiles:

Profile A:
SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems

Profile B:
SAML V2.0 Deployment Profiles for X.509 Subjects

Since the two profiles address exactly the same use case (section 3 of
both profiles), you might expect near perfect alignment.  They do,
however, differ in the following respects:

A: none
B: The <saml:Assertion> element MUST contain a <saml:Conditions>
element with NotBefore and NotOnOrAfter attributes.

A: The <Assertion> element MUST contain an <AudienceRestriction> element that
includes the service provider's unique identifier as an <Audience>.
B: The <saml:Assertion> element SHOULD contain a <saml:Audience>
element whose value is identical to the value of the <saml:Issuer>
element in the request.

A: The <NameID> element MUST have a Format attribute whose value is
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName, as defined
in Section 8.3.3 of [SAMLCore].
B: The <saml:NameID> element MUST have a Format attribute whose value
is urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName. Thus the
DN value of the <saml:NameID> element MUST satisfy the rules of
section 8.3.3 of [SAMLCore]. Moreover, for the purposes of this
deployment profile, the DN value MUST satisfy RFC 2253 [RFC2253].

A: none
B: The <saml:Subject> element [in the AttributeQuery] MUST NOT contain
a <saml:SubjectConfirmation> element.  The <saml:Subject> element [in
the Response] (which strongly matches the subject of the query
[SAMLCore]) SHOULD NOT contain a <saml:SubjectConfirmation> element.

Security Requirements
A: Since this profile extends the SAML V2.0 Assertion Query/Request
Profile (section 6 of [SAMLProf]), a Basic Mode requester SHOULD
authenticate and ensure message integrity to the responder, and vice
B: The service provider MUST authenticate itself to the identity
provider. The identity provider MUST authenticate itself to the
service provider.

Except for the NameID/@Format discrepancy (which has been discussed ad
nauseam), these discrepancies are fairly easily reconciled, I think.
The most interesting differences are the security requirements, which
directly influence the normative language surrounding Audience.

Your comments on any of this is most welcome.

Tom Scavo
NCSA/University of Illinois

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]