Title:
In the
0.3 version of the document, I am unclear about the box at the top of page 11
that starts "Alternate means of identifying the assertion" Are these design
alternatives or are you proposing to support a number of different ways of
identifying the same assertion?
Without regard to the answer to that question, have you considered the
alternative of using tickets which are simple references and contain no
information in themselves? For example, create a random number X, use the hash
of X as the assertion id, put the domain and X in a cookie (or
wherever).
The
problem with using a reversible encryption of the ticket is that given that SAML
will be used for interop between a large number of independant orgs, the key
will be a) potentially known to a lot of people and b) hard to change.
Unless we invent some key management protocol this will make it easy for
attackers to spoof tickets.
Hal
-----Original Message-----
From: Philip Hallam-Baker
[mailto:]
Sent: Wednesday, March 28, 2001 4:04
PM
To: Philip Hallam-Baker; ''Security-Core
(E-mail)'
Subject: RE: conference call - March
29
All,
I am still working on the attached
trying to get it into some sort of shape. Problem is trying not to spend time
writing stuff that should flow from the use cases and
requirements.
I'll try to get a version 0.4 for
tommorow.
Phill
Phillip Hallam-Baker
Principal Scientist
VeriSign
Inc.
781 245 6996 x227
-----Original Message-----
From: Philip Hallam-Baker
[mailto:]
Sent: Tuesday, March 27, 2001 2:41
PM
To: ''Security-Core (E-mail)'
Subject: FW: conference
call - March 29
March 29th
12pm EST
Running time :appx. 1
hour
Confirmation # 8532838
Dial in number : 1.904.779.4702
