Title: Comments on Core 12
Phill/(Prateek/Chris/David) - In response to my comment number 4, you
suggest an addition to Core, Section 4. I can take a run at producing some
text, if you like.
There
is another authentication protocol that I would like to see added (could even
volunteer text). This is "authorization by signature". So,
the authentication data would be a document and a signature (like a
challenge/response, but without the challenge). In this case, the signed
document could be though of as an "instruction", and checking the
signature on the "instruction" and the attributes of the signer
effectively answers the question "is the signer authorized to issue the
instruction?"
In
response to comments 3 and 12, you seem to imply that (while you agree with the
comment) you don't have the authority to make the change. That leads me to
ask: how do we get issues like these considered and decided? Does it
require a request to Hal to include them on the Issues list? Best
regards. Tim.
-----Original Message-----
From: Hallam-Baker, Phillip
[mailto:]
Sent: Tuesday, August 07, 2001 1:47
PM
To: 'Tim Moses'; 'OASIS Security Services
group'
Subject: RE: 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
