Re: [security-services] revised conformance spec

["Eve L. Maler" <eve.maler@sun.com>]

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