Comments on "SAML Core Assertions, 0.2"

["Mishra, Prateek" <pmishra@netegrity.com>]

 My comments reference document:

draft-sstc-core-vmodel-examples-01.pdf

(1) Ticket Example (1.1.2)

Defining a fixed size "small" ticket aka "assertion
reference".

(a) Assertion_ID: This appears to be a combination of a
ticket issuer id and an assertion number.

I do not see how 7 bytes are enough to represent 
BOTH the ticket issuer and the assertion number. While an IP
quartet may be enough to identify the ticket issuer (BTW, 
I would avoid identifying this with the actual address
of the AP server), it seems to me 8 bytes (64-bit number) would
be minimally required to represent assertion numbers. There is no
need to call out a specific format for the assertion number BUT we
do need enough space so that APs can create a unique
assertions over large time periods.

(b) Account: This one really caused me some real difficulty. Is
this a resolved "name" of the subject? At its simplest I would imagine
this as a pair of strings ("alice" X "finance"). In many common cases,
it could take the form of a X.509DN (cn=alice,ou=finance,co=...)
or some kind of one time string token (surely at least 8-10 bytes?).
IMHO, Most "reasonable" schemes will require a fairly large
size representation.

The question arises why such a "name" is required in addition
to an assertion_ID? Is the main issue to ensure that the ticket 
itself be a complete assertion about a subject(mid-page,p.7)?

(c) Authentication: I would question the need for a mandatory signature
here. The assertion itself is provided separately
over some mutually authenticated channel between the AP and RP. Why is there
a need for a signed ticket as well? What is the threat model here?

2. Assertion (1.1.5)

My main comment here is that it is extremely unlikely that BizEx Hub
will maintain AuthZ information about SPECIFIC resources at Carol's
store (e.g., http://store.carol.test/finance) unless both
entities belong to the same security domain. This comment
is also relevant to the example on the bottom of p.7. Basically,
the issue here is that Carol manages her AuthZ INDEPENDENT of
specific AuthZ APs (sites providing authenticated users).

In the use-case where BizEx and Carol belong to distinct
security domains, the BizEx hub will authenticate Alice and 
issue some type of AuthZ information defined by the business
relationship between Carol and BizEx. I guess the URN rights
identifier would cover this case; alternatively (and more
likely) Carol and BizEx will agree upon some specific 
AuthZ XML schema to represent these rights.

Following, thru this analysis I have one final issue: the AuthZ
decision at Carols site is based on the assertion issued at the
BizEx site. Let us assume that Carol utilizes a PEP ---> PDP
type of AuthZ decision engine. In such a case, the PEP --> PDP
protocol may need to include assertions originating from various
different sources (BizEx exchange, SomeOther exchange, ...) 
in determining whether a subject is permitted access to a resource. 
This is one of the core pieces of the S2ML Authorization service
protocol and some equivalent would be required within this
design as well. 


- prateek