Title: Comments on Core 12
Phillip Hallam-Baker FBCS C.Eng.
Principal
Scientist
VeriSign Inc.
781 245 6996
x227
-----Original Message-----
From: Tim Moses
[mailto:]
Sent: Friday, August 03, 2001 2:54
PM
To: 'OASIS Security Services group'
Subject: Comments
on Core 12
Colleagues - I have the following
observations/comments/questions on Core 12. Best regards.
Tim.
1 (major). Section 1. Definition of Authentication
assertion. This definition is a bit limiting. How about ... " ...
an assertion by the issuer that the subject was authenticated by a particular
means at a particular time, and including information by which a relying party
can confirm that an entity claiming to be the subject of the assertion is,
indeed, the subject. The assertion may (but does not have to) include a
name for the subject. The assertion may (but does not have to) contain
authentication information by which the relying party can authenticate the
subject. In the case of a bearer token, the authentication information
may be missing. In which case, the relying party must deduce from the
environment that the presenter of the assertion is the subject."
I
thought the 2nd ammendment was about bearing arms, not
assertions
I agree up to the point where bearer assertions
are mentioned, I think they should simply be one AuthenticationCode
mechanism
2 (minor). Section 1. Attribute assertion. Is
there a reason for saying "is associated with", instead of "possesses"?
"Possesses" seems more straight-forward.
Aggh, I didn't like the wording, I don't think
possesses captures the meaning either.
3 (major). Section 1.2. We should allow an
AssertionSpecifier to be verifiably-linked to a specific assertion, i.e. it
may be a digest of the assertion. This is hinted at in 1.1.1.1.
However, for the linkage to be verifiable, we need identifiers for the
specifier type and the digest algorithm.
I
would be happy to agree to something like that. It was only left out
because it was not brought up in the TC.
4 (major). Section 1.3.2.1. We should allow the
authenticator to be a digest of a data object (e.g. XML document), then we can
attach assertions to objects.
Steve raised the same point, that would be
another Identifier to define in section 4:
4.1.7
Object Authenticator (SHA-1)
If
someone writes the text I can put it in.
5 (minor). Section 1.3.2.1. Can we be more specific
about the use of "AuthData"?
The idea
is that the use of the field is specified mechanism by mechanism in section
4.
It
should be AuthenticationData however...
6 (minor). Section 1.4.1. The "AuthenticationCode" and
"Audience" elements, together, serve the same purpose that the
"certificatePolicies" extension of X.509 serves. Can be learn anything
from the experience with X.509?
Oh
I think we did :-)
7 (minor). Section 1.4.1. Why did we choose the term
"AuthenticationLocale"? Aren't we actually identifying the
authentication authority? So, isn't that a more appropriate term?
Whatever.
8 (major). Section 1.5.1.1. We should allow the "object"
element to contain a digest of a data object, or the object itself.
Could do, I don't see why not. Might be additional
reason to do the reorg suggested by David O.
9 (minor). Section 1.6.1.1. Does the syntax express the
relationship that there can be one or more attributes, each with zero or more
values?
Yes
10 (major). Section 1.7.2. "Audience" should be able to
specify a "use", as well as a "community".
Could
reword, the intention is that the Audience can be specified to be the
people who agree to use the assertion for a particular
use.
11 (major). Section 2.2.2. I believe there are
circumstances under which the SAML request must convey "both" an assertionID
and a query. I have an outstanding action to explain where this need
arises.
OK. will wait for the
explanation
12 (major). Section 2.3.1. I believe the requester needs
an opportunity to specify the authentication protocols that it supports and
the space in which the subject's name should be expressed.
I
have no reall objections, but it is an addition
13 (minor). Section 2.4. Delete: "The response will be
in the form of an Attribute Assertion", and replace it with "A successful
response will be in the form of one or more Attribute Assertions".
OK
14 (major). Section 2.4.1. As currently defined, the
"CompletenessSpecifier" is redundant. The requester can only ask for the
set of attributes that it is qualified to receive. So, there is no need
to specify behaviour in the event that there are other attributes that it is
not qualified to receive.
See other post
15 (major). Section 2.5. The PEP should be able to
supply additional information, possibly in the form of "environmental
assertions" upon which the PDP may base its decision.
I
think that the 'evidence' approach is much more general than just for
Authorization queries and could well be promoted higher in the hierarchy so
any query could specify supporting assertions.
------------------------------------------------------------------------
---------------
Tim Moses
Tel: 613.270.3183
Phillip Hallam-Baker (E-mail).vcf
