So "process" may be ignoring or sending a fault/error.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Philpott, Robert" <>
"Philpott, Robert" <>
01/05/2005 09:18 AM
To
"Philpott, Robert" <>, "Scott Cantor" <>, <>
cc
Subject
RE: [security-services] Proposed addition to Section 3.3 of Conformance
Any other comments? If not... Prateek, can you make the proposed edit
and add a statement about consent not being MTI?
--------------------------
Conforming SAML implementations must provide facilities that permit
consumers and producers of SAML messages to support all constants
described in Sections 8.2 and 8.3. SAML message consumers must be able
to process messages with constants present in these sections. SAML
message producers must be able to create messages with constants present
in these sections.
A SAML implementation can provide the facilities described above through
direct implementation support for the identifiers or through the use of
supported programming interfaces. Interfaces provided for this purpose
must allow the SAML implementation to be programmatically extended to
handle all identifiers in section 8.2 and 8.3 that are not natively
handled by the implementation.
Note that only sections 8.3.7 (persistent name identifiers) and 8.3.8
(transient name identifiers) define normative processing rules for the
producer of such identifiers. The remaining identifiers in sections 8.2
and 8.3 specify no normative processing rules. All normative processing
rules in sections 8.3.7 and 8.3.8 must be supported. Since no normative
processing rules exist for the other identifiers in 8.2 and 8.3,
generation and consumption of these identifiers is meaningful only when
the generating and consuming parties have externally-defined agreement
on the semantic interpretation of the identifiers.
<need additional text explaining that the consent identifiers (section
8.4) are not MTI>
---------------------------
Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:
> -----Original Message-----
> From: Philpott, Robert [mailto:]
> Sent: Wednesday, January 05, 2005 9:29 AM
> To: Scott Cantor;
> Subject: RE: [security-services] Proposed addition to Section 3.3 of
> Conformance
>
> Agree on both points.
>
> Rob Philpott
> Senior Consulting Engineer
> RSA Security Inc.
> Tel: 781-515-7115
> Mobile: 617-510-0893
> Fax: 781-515-7020
> mailto:
>
> > -----Original Message-----
> > From: Scott Cantor [mailto:]
> > Sent: Wednesday, January 05, 2005 1:40 AM
> > To: Philpott, Robert;
> > Subject: RE: [security-services] Proposed addition to Section 3.3 of
> > Conformance
> >
> > > A SAML implementation can provide the facilities described
> > > above through direct implementation support for the
> > > identifiers or through the use of supported API's. API's
> > > provided for this purpose must allow the SAML implementation
> > > to be programmatically extended to handle all identifiers in
> > > section 8.2 and 8.3 that are not natively handled by the
> > > implementation.
> >
> > Can we s/APIs/programming interfaces? Sounds a little less wonkish
for
> the
> > document to me.
> >
> > > Note that only sections 8.3.7 (persistent name identifiers)
> > > and 8.3.8 (transient name identifiers) define normative
> > > processing rules for the identifiers. The remaining
> > > identifiers in sections 8.2 and 8.3 specify no normative
> > > processing rules. All normative processing rules in sections
> > > 8.3.7 and 8.3.8 must be supported.
> >
> > The only normative rules that apply to an SP are that you shouldn't
> store
> > a
> > transient (so it's not a "do this", but a "don't do this"). I think
> it's
> > worth saying that, maybe changing the first sentence to:
> >
> > "Note that only sections 8.3.7 (persistent name identifiers) and
8.3.8
> > (transient name identifiers) define normative processing rules for
the
> > *producer of such* identifiers."
> >
> > -- Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: -
> open.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
