Title: RE: [security-services] Proposed addition to Section 3.3 of Conformance
Does it make sense to add a clarification statement around what consumption means (i.e., what it does not imply for conformance). For example, changing the last sentence in the second paragraph to:
-------------
The remaining identifiers in these sections do not specify normative
processing rules. Therefore, their generation and consumption will only
be valid when both providers share common values for these identifiers.
Additional mapping or federation of these identifier formats is
implementation specific.
-------------
The specific use case I'm trying to address can be viewed with this example:
- a conformant SP: so for a conformance test, the tester selects that the
SP should be configured to be able to consume X509SubjectName formats.
- the SP can use a programmtic API to map the name in X509SubjectName format
to the actual user somehow. For Saml persistent identifiers, this is
well-defined. Otherwise this is variable.
What the API maps the value to is implementation specific
(i.e., it could be associated with the actual cn in the subject name, it
could be a directly look up of the subject dn, etc...) and not defined by
Saml.
So it is very realistic that 2 conformant saml implementations that support
X509SubjectName formats will not interoperate without some out of band
mappings being set up or some other non-Saml understandings. I guess the
emailAddress is a better example as 2 providers may very well have their
own email addresses for the same user.
This led to my stmts above regarding the need for 2 providers to share the
same id values (as was the case in last year's RSA interop I believe).
I would also like to confirm that support for the persistent name identifier
and therefore the normative text around it will be required for conformance
based on the wording changes below. I ask this because on the call, I asked
if there were any objections to saying that at least this one would be
mandatory if we narrowed the list. And there seemed to be objections -- so I
would assume those objections would no longer be relevant.
Tom.
-----Original Message-----
From: Philpott, Robert [mailto:]
Sent: Tuesday, January 04, 2005 1:59 PM
To: prateek mishra;
Subject: RE: [security-services] Proposed addition to Section 3.3 of
Conformance
Proposed modifications... feel free to wordsmith further...
-------------
Conforming SAML implementations must provide facilities to permit
consumers and producers of SAML messages to support the constants
described in Sections 8.2 and 8.3. These facilities can be provided
through direct implementation support for the identifiers or through the
use of supported programmatic API's that allow the SAML implementation
to be extended in ways that adds support for the identifiers.
SAML message consumers should be able to process messages with constants
taken from Sections 8.2 and 8.3. SAML message producers must be able to
create messages with constants taken from Sections 8.2 and 8.3. Note
that sections 8.3.7 and 8.3.8 prescribe normative processing rules that
must be adhered to for persistent and transient identifiers. The
remaining identifiers in these sections do not specify normative
processing rules.
<need additional text explaining that the consent identifiers are not
MTI>
-------------
Rob.
> -----Original Message-----
> From: prateek mishra [mailto:]
> Sent: Tuesday, January 04, 2005 11:20 AM
> To:
> Subject: [security-services] Proposed addition to Section 3.3 of
> Conformance
>
> Add after line 196:
>
> SAML consumers should be able to process messages with
> constants taken from Section 8.2-8.4. SAML generators
> should be able to create messages with constants taken
> from Section 8.2-8.4. Sections 8.3.7 and 8.3.8
> prescribe normative processing rules for persistent
> and transient identifiers requiring implementation by
> conformant implementations. Sections 8.2-8.3 do not
> specify normative processing rules for any of the
> remaining identifiers. The means by which SAML
> generators obtain and record consent is outside the
> scope of the conformance document
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: -
> open.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
