OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Structural Issues


	Attached is a zip file of my various experiments in schematology.
There are four directories

core-12        core-12 draft schema with one misc typo corrected
renamed        core-12 with the renaming changes
substitution   declares substitution groups
uri            uses uris to specify NameIdentifiers

	Since the point of the exercise is to examine the impact on
extension schemas i have defined two extension schemas

xtaml   is XTASS implemented on top of SAML
xacl    is an ACL type language implemented on top of SAML

NOTE WELL: The point is that the group can only constrain the extension
schema in its own schema.

There are also a bunch of example fragments whose purpose should be
clear(ish). These all validate but I have not included internal elements
that would be distracting from the point being made.

All the examples, schemas etc. were validated using XMLSpy 3.5. I have not
yet updated to 4.0. As a result the old schema is used.

In addition to renaming I also removed the xsd: prefix throughout for
clarity. In the original schemas one used it and the other did not.

Some toplevel points:

1) 	xtaml and xacl use substitution groups in all cases regardless of
whether the renamed or the substitution group schema is used.
	Therefore there is no point in not using substitution groups in the

2)	Even if substitution groups are specified an implementation can
still choose to use the xsi:type specifier instead to assist a validator
without the neccessary schema.

3)	If the objective is to allow any SAML processor to be able to
process the envelope of the saml assertion (conditions, advice, header
attributes) and then pass the actual statements on to another processor then
a better way to achieve that effect is to introduce a sub-element of
<Assertion> for the purpose. This is the approach taken in XACL which
introduces a 'statement' element that is then extended to create the
Membership and Access Control List statements.

4)	The URI schema contains two sets of changes to simplify the
specification of xacl (for which read likely xacml needs). These are first
the promotion of some saml types to be toplevel and second the introduction
of a URN scheme to specify the username and account (reduces verbiage

Detailed discussion:

In the 'renamed' schema we are foced to use xsi:type for saml assertions:

<Assertion AssertionID="23-0832-0wa4908245-we2380rf2w-42" Issuer="Phill"
IssueInstant="2001-08-08T10:23:21Z" Version="1.0"
xsi:type="AttributeAssertionType" ....

However this DOES NOT prevent XTAML specifying substitution groups:
	<element name="KeyDelegationAssertion"
type="xtaml:KeyDelegationAssertionType" substitutionGroup="saml:Assertion"/>

XACL defines an assertion that takes a list of statements:
<AccessControlPolicyAssertion ../>
	<AccessControlList ...>
	<AccessControlList ...>
</AccessControlPolicyAssertion ../>

if the same mechanism were promoted into SAML this would allos all saml
assertions to use the same package and for generic 'saml assertion
processors' to be built:

<Assertion ../>
	<AttributeStatement ...>
</Assertion ../>

<Assertion ../>
	<AuthenticationStatement ...>
</Assertion ../>

<Assertion ../>
	<AuthorizationStatement ...>
</Assertion ../>

<Assertion ../>
	<xtaml:KeyDelegationStatement ...>
</Assertion ../>

<Assertion ../>
	<xtaml:MetaAssertion ...>
</Assertion ../>

<Assertion ../>
	<xacl:AccessControlListStatement ...>
</Assertion ../>

<Assertion ../>
	<xacl:MembershipStatement ...>
</Assertion ../>

The requirement in XACL to be able to package up lists of assertions might
well be worth specifying as a separate case, this would allow the type of
statement bundles defined in XACL to be implemented in the same framework:

<AssertionList ../>
	<xacl:AccessControlListStatement ...>
	<xacl:AccessControlListStatement ...>
	<xacl:AccessControlListStatement ...>
	<xacl:MembershipStatement ...>
</AssertionList ../>


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
781 245 6996 x227  
 <<Phillip Hallam-Baker (E-mail).vcf>>  <<SAML Schema.zip>> 

Phillip Hallam-Baker (E-mail).vcf

SAML Schema.zip

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC