RE: PDF of some SAML ideas.

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Hi Phill,
I have got some comments on these documents. I have tried to structure
this email so that the most important comments are first. I suspect
most people will not want to read the XTASS-details and the
strawman-details sections (assuming they want to read any of the rest
of it ;-)).
Best regards,
Nigel.

XTASS - high level comments
-----
If I understand this correctly one of the key ideas is that URIs are
used to denote authorizations. Determining the correspondance between
URIs and resources to which access is granted is application
specific. I think we should go a little further than this for SAML, as
S2ML does, otherwise I wonder what degree of interoperability will be
possible.

Section 2.6.5 talks about the justification for not including
delegation mechanisms that state precisely for what functions a peer
is recognized to act, saying it would make XTASS more complicated. In
my opinion as XTASS stands you cannot introduce such a
mechanism. Introducing such a mechanism requires a notion such as
subsetting on the authorization space. Since the semantics of
authorization is outside of XTASS, you cannot specify such a
relationship. 

Strawman architecture - high level comments
--------------------- 
When I first saw this document, I was a bit confused about its
pupose. I note that you said it was "more an extended position
statement". I felt it sat between the use-case and protocol
documents. On reflection, it seems to me that there is a lot of
material that has much in common with the protocol document that Tim
Moses recently circulated. 

I strongly support the idea that SAML should support sequences of
authorization messages being used to make an access control decision
(i.e. combining assertions).

XTASS-details
-----------
The document describes breaking the specification into two tiers
(direct assertions and meta assertions). However, it also refers to
tiers 1 to 4 protocols. What are tiers 3 and 4 - could not find a
definition?

Section 3.2.2 seems to be suffering from a cut and paste problem. The
table defines the chainlength sub-element

Some of the definitions use the s0 and s1 namespaces. Where are these
defined?

Strawman architecture - details
-------------------
Section 2.1
<quote>
The application program that is requesting access to a resource. In
each case it is the client that initiates a sequence of protocol
messages.
</quote>
In the use cases being consided there are cases when the client does
not directly initiate the message sequence. Some of the session
management scenarios illustrate this.

Sections 2.2 and 2.3 I believe the PDP and PEP terms are being
mis-applied. At least when I wrote a scenario equating the issuer with
the PDP, HAL corrected me. The relying server may not be the same
thing as the PEP.

Section 2.3
<quote>
Although a resource controller may subordinate policy decisions to a
remote resource we exclude by definition the possibility of
subordinating policy enforcement 1 .
</quote>
I could not understand this or the footnote.

Section 3.2 contained a discussion of using the ticket to communicate
keying material. I assume this would be an extension, rather than
something that would be specified in SAML.

Section 5.4
<quote>
3, 4 As in case 2
</quote>
I didn't understand what steps this was illustrating.

Section 5.4.2 in the protocol example discusses a "Listen" element. I
couldn't see where this was defined. Also in this protocol example
steps 5 and 6 seem to be suffering from a cut and paste problem. At
least I couldn't make sense of them

> -----Original Message-----
> From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Friday, February 16, 2001 11:55 PM
> To: Security-Use (E-mail); 'Security-Core (E-mail)
> 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