RE: Core 10 Draft document

["Mishra, Prateek" <pmishra@netegrity.com>]

Philip,


> 	The errors fixed were to remove the definition of elements of
> certain abstract types that are not intended for actual use
> (Assertion,
> Request, Response) and to create elements of the three
> defined assertion
> types.


as Chris points out these do not constitute errors. These have
been provided to make the overall schema work (e.g., Chris's
discussion of the <AssertionSpecifier> element). There is 
also an issue of extensions which has been carefully argued
in Chris's document.

At any rate, as far as the group is concerned here is the situation:

http://lists.oasis-open.org/archives/security-services/200107/msg00090.html

includes *valid* schema for assertions and protocols and discussion
documents which include design issues and justification. Considerable
effort has been invested in communicating with David O. and Philip
concerning this schema.


These have been subsequently revised by Philip and a somewhat 
modified schema published in core 10.

- prateek



My understanding of schema may be at fault here, but I had done this on
purpose. My understanding of type substitution (as opposed to element
substitution) is that if you declare an element and assign it a type
that
has been declared abstract, then what you are really saying is "This
element
will have its type replaced at runtime with a concrete descendant type".

The idea is that you have an element such as <Assertion>, for example,
that
is of an abstract type (I.e. "AssertionType"). Since the type of the
element
is abstract you can not instantiate it as such. However, you could
instantiate it with a descendant type that is concrete.

So while you could not have an <Assertion> element, you could have an
<Assertion xsi:type="saml:AuthenticationAssertionType"> element.

Doing the substitution this way allows you to declare containers, such
as
the AssertionSpecifier for example, that will contain an of the
descendant
types.

Unless my understanding is wrong, and it may well be, if you declare
AssertionSpecifier as:

<element name="AssertionSpecifier" type="saml:AssertionSpecifierType"/>
<complexType name="AssertionSpecifierType">
	<choice>
		<element ref="saml:AssertionID" />
		<element ref="saml:Assertion"/>
	</choice>
</complexType>>

then you can't put an <AttributeAssertion>, for example, into it unless
you
create a substitution group with the <Assertion> element at its head and
assign <AttributeAssertion> to that group. Thus having global elements
for
the descendants, without a substitution group, is useless since you
couldn't
put them in anyway.

If I'm completely off here, please let me know, but based on what I
gathered
in my quick readings of the schema rules, the way it was done would
work. Of
coure the other scheme would also work with appropriate substitution
groups
being defined, but results in the need for many more elements at the
global
level. (The issue of which way to do this is discussed, by the way, in
the
schema issues section of the Orchard-Mahler document).

> 3) Use of element/ref definitions
> 	Still some work to be done here, when to use a ref and when to
> define an element type?

Again, this was done very consciously, but may have been done
incorrectly if
my understanding of the schema rules is wrong. Here I thought the idea
was
that you created an element at the global level if you were going to use
it
in more than one place, and then you used "ref" to refer to that element
wherever you wanted to use it. So, for example, the <Evidence> element
is
declared globally and then used by reference in both the
AuthorizationDecisionAssertionType, and in the AuthorizationQuery.

I made an effort to ensure this was set up to create global elements
only in
the cases where the elements would be used more than once in the
definition
of other types, or in cases where the element might need to be reference
by
outside specifications.

Again, if my understanding is wrong, please let me know, as I am by no
means
a schema expert. I'd be delighted to see the specific issues you have
with
this.

5) Descriptive text
> 	Quite a few elements are lacking descriptive text, will
> take this
> from wherever it can be found for the core11 draft.

Which ones in particular are you lacking text for? I thought they were
all
addressed to some degree or other in the discussion papers.


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



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to:
security-services-request@lists.oasis-open.org