Hi Bob,
Some comments on conform-spec-10; I didn't look at the test cases, but some
of them might be affected by suggestions I make below:
- The footer was explicitly set to -08 and the (static) then-current
date a while back; you'll need to change both each time you publish.
- I note that the required/optional elements language is still in
there (lines 140-144, 159-160, 172-186, and elsewhere), even though
I'm quite sure we agreed to change this at least a couple of times.
I think what we want is a statement that any SAML-consuming
implementation must handle all *valid* SAML elements (including ones
that are optional according to the schema) in a conforming fashion,
but that SAML-producing implementations need not produce *optional*
SAML elements.
- In the other specs, I believe "requestor" has consistently been
spelled "requester", and "artefact" has been spelled "artifact".
- Line 215 contains a phantom section head that should be deleted.
- It would be nice to give an italic example of an implementation that
functions as a producer (e.g., an authentication authority) and not
a consumer.
- Even though I guess I contributed to the change of direction for
this document :-), I have to admit that I'm not sure I understand
how Table 1 works as it currently stands. Here's what I have been
picturing (could be done as a table too, but this was easier in
email):
=================
SAML Protocol
[] SOAP-over-HTTP binding
[] (eventually we'll have more here)
[] Additional non-standard bindings: _______________
[] Requester (produces and sends a request)
- Queries produced (i.e., statement types requested):
[] AuthN
[] AuthZ (i.e., I'm a PEP)
[] Attrib
- Other information
(don't know what else this might include)
[] Responder (returns a response; a "SAML authority")
- Query types answered (i.e., statement types provided; "authority type"):
[] AuthN
[] AuthZ
[] Attrib
- Other information
(don't know what else this might include)
SAML Profiles
[] Browser/artifact profile
[] Consumer (receives artifact, requests/receives SSO assertion)
[] Producer (returns SSO assertion)
- Other information
(don't know what else this might include)
[] Browser/POST profile
[] Producer (sends SSO assertion)
[] Consumer (receives SSO assertion)
- Other information
(don't know what else this might include)
[] SOAP profile
[] Sender
[] Uses SenderVouches format
[] Uses HolderOfKey format
[] Receiver
[] Supports SenderVouches format
[] Supports HolderOfKey format
- Other information
(don't know what else this might include)
=================
Eve
At 10:32 AM 1/31/02 -0500, Robert Griffin wrote:
>hi -
>
>i've attached a revised conformance spec, containing a new section 2.5
>that stipulates that for any element in the schema that specifies an
>"unbounded" max value (included in table in conform spec), any conforming
>application or implementation must support a max value of at least 1000
>(pretty arbitrary value, i know...).
>
>i didn't modify test cases; i think the stipulation is reasonably covered
>by the pass/fail criteria in the current test case descriptions, which
>call out support for all required elements of assertions, requests and
>responses.
>
>comments/corrections?
>
>bob
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com
