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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

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


Subject: Core Assertions, protocol example strawman



All,

	Attached as a word document is the set of protocol examples I have
been working through.

	These very concrete, showing very specific examples of message
exchanges. I generally work on examples of this type for a while before
extracting the abstract assertions back out again.

	The intention is not to model specific use cases per-se, but instead
to illustrate points of distinction at the architectural level.

	I have employed two approximations, first the ticket encoding is
absolutely bogus, actually it is just random base64 encoding from another
spec chopped to the right length for our specific examples, second I have
trimmed the XML syntax somewhat for clarity removing all the close element
tags.

	The document is pretty consistent with my 'three legged' model and
Stephen's PDP/PEP distinction. For the sake of completeness I have included
an example with authorization policy, this is mainly to indicate that there
is an important box here that is out of scope and needs to stay that way.

	These configurations represent only some of those possible, I have
left the proxy type model and the multiple issuing server type examples to
people's imagination. In particular it is not strictly necessary for the
ticket issuing server and the assertion issuing server to be the same, or
even to communicate.

	The document takes the view that there is no necessary and intrinsic
semantic distinction between an assertion and a ticket, it is all just a
matter of syntax. 

	The approach is largely directed by XML Signature/XKMS and uses some
parts (but certainly not all) of XTASS. In particular the tier 2
meta-assertions are not used.

	The piece I am having a little difficulty with is expressing the
semantics of 'by presenting this signed/MACed assertion the holder is
authenticated' in the XML side. 

	Tomorrow I will go through the use case strawman and attempt to work
out the correspondence.

		Phill

Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
 

Phillip Hallam-Baker (E-mail).vcf

SAML-Core.doc



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


Powered by eList eXpress LLC