[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
Security Assertions Markup Language.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC