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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

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


Subject: PDF of some SAML ideas.


Because I have not yet got my HTMLifier working right I am enclosing a set
of design ideas in pdf. If anyone wants the Word doc before I have got my
HTMLifier to behave please contact me.

I am also forwarding X-TASS since I would now like to propose that we use
X-TASS as a framework for addressing the SAML issues (I thought I would
assume the current leader wins the name change rather than invent YAWATWCP).

The original idea I had had was to propose X-TASS as a followon item to the
XKMS working group (when it exists). However SAML looks likely to pre-empt
much of the same work earlier. This then leaves open the question of how to
relinquish change control of XTASS and where to relinquish it to. 

The proposal enclosed is in some respects more abstract and in others more
concrete than those discussed in the use case group. I believe that the
basic data flows that are expressed in the use case group can be supported,
together with some additional ones I have been considering. It is not
necessarily a proposal for document text itself, more an extended position
statement.

The basic architectural cut I have made is to propose two separate types of
credential data:
1) Assertions (big, bulky XML encoded etc - here I use X-TASS as the
framework)
2) Tickets, (small enough to encode in URL, may be authenticating, may be
encrypted).

I have also done a cut on a ticket format, not because it was particularly
necessary at this point but because it was easier to define the bit patterns
than handwave. I may have gone a little overboard on the
extensibility/compact encoding bit however I dislike fixed length fields. I
wanted to have enough detail to allow someone to knock up a discussion
prototype, hence the bit level stuff.

I think the proposal incorporates most of the material from
S2ML/Auth-XML/ITS etc as discussed in a bunch of 1-1 telephone calls over
this week with various folk who happened to be in.


The main departure from the S2ML model is that the various AC/AZ etc stages
are seen as being a continum rather than as sharply defined and requiring
different interfaces. So it is quite likely that an S2ML like protocol
intercange would go on, only the distinction between the stages would not be
sharply enforced.

The main departure from the Auth-XML model is that the identifiers to which
credentials, rights etc are bound are all in URI space. This makes it much
easier to handle the multi-domain model and allows the same protocol to ask
questions like "Can Alice access the finance Web Page (http://...)" and
"Does Alice have the finance privilege".

The basic Jamcracker/ITS model is there, only augmented with more
comprehensive support and presented as an optional extra feature that
issuing and relying servers may support at their option if they thing they
need it. We can argue as to whether the minimal additional complexity I am
proposing is really required. However we did have this argument in PKIX/X509
land and discovered the answer was 'yes'. I suspect that the model that is
most scalable is the 'pushmepullyoo" model described which involves an
enterprise listener resource.


Appendices that would probably be helpful are a draft pseudocode
implementation of a relying server and issuing server or maybe to give an
example of a messaging sequence.

Another item for the 'we arn't doing that' list is that when a relying
server asks an issuing server 'is Alice allowed to access X' a possible
response is an access control list saying 'A party with the Plumber property
can do that but not on a Wednesday, Bob can always do it. On the other hand
people who did want that facility could always make like the little red hen
and encode their own X-TASS extension schema for ACLs.

	Phill


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

Phillip Hallam-Baker (E-mail).vcf

Xtass.pdf

Security Assertions Markup Language.pdf



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


Powered by eList eXpress LLC