RE: Consensus Draft schema and discussion papers.

[Tim Moses <tim.moses@entrust.com>]

Title: RE: Consensus Draft schema and discussion papers.

Chris - This concerns the ISSUE PRO-02 at line 140 of the protocols schema discussion (draft-sstc-protocol-discussion-00.doc).

The "other identifier" you refer to is what I called "reference" in the message that I sent yesterday entitled "first contact" and dealing with the browser profile "pull model".  I think this reference can be structurally identical to the artifact.  The relying party needs to glean from it the identity and location of the issuer, so that it can request an assertion.  The SAML query, in this case, must be able to accommodate both the assertion ID, obtained from the artifact and the list of desired attributes.

Strictly, the assertion may not exist at the time that the reference is included in the redirection by the issuer.  Nevertheless, the artifact uniquely identifies an authenticated individual to the issuer, so an assertion matching the relying party's requirements can be constructed when the corresponding SAML query is subsequently received.

Best regards.  Tim.

-----Original Message-----
From: Chris McLaren [mailto:cmclaren@netegrity.com]
Sent: Monday, July 23, 2001 1:53 PM
To: security-services@lists.oasis-open.org
Subject: Consensus Draft schema and discussion papers.

Here, slightly delayed from Friday due to Visio-related problems you don't
need to know about, are the drafts of the consensus schema and some
discussion papers related to them.

The files attached to this message should be as follows:

draft-schema-assertion-10.xsd: the draft of the core assertion schema

draft-schema-protocol-10.xsd: the draft of the request/response protocol
schema

xmldsig-core-schema.xsd: the XML_DSIG schema; this is included as a
convenience for people using schema tools, as this is imported into our
schema to provide the <ds:KeyInfo> element

draft-sstc-core-discussion-00.doc: A word document discussing the core
assertion schema and providing some example of how the various assertions
would look.

draft-sstc-protocol-discussion-00.doc: A word document discussing the
request/response protocol and providing some examples of how the documents
might look.

It is my understanding the Phil will revise the formal specifications
document to update it to this schema, but the discussion documents are
provided to act as an informal internal explanation of the schema and it's
connection to the F2F whiteboard results. Specific issues are also called
out in the discussion documents.

A couple of points:

0) My personal Visio issues continue, and I have not been able to prepare
the diagrams that I had intended to accompany these discussion documents.
I'm going to keep messing about with it and will issue diagrams in some form
or another (mostly likely as a companion document) as soon as I can.

1) We don't present requirements for identifier syntax for such things as
assertion IDs, version, Issuer fields, etc., but rather have left these as
open issues. Naturally, however, in order to provide examples we have had to
provide something; this is not intended to be normative, but rather just to
allow for a complete example. For example, string representations of GUIDs
have been used in the examples for Assertion IDs--this is not intended as a
suggestion that the TC specify that IDs will be GUIDs, but is just in the
way of an example. (For the record, my _personal_ stance on almost all the
identifier questions is that the less formal rules on content form that
there are the better.)

2) The schema is presented according to the October 2000 version of the
schema language. At some point we should probably update it to the 2001
specification. Among other things this means that uriReferences would become
"anyURI"s and "timeInstant"s would become "dateTime"s.

Chris
--
Chris McLaren, Principal Engineer
B2B Research Group  Netegrity, Inc.
cmclaren@netegrity.com   chris.mclaren@ieee.org