Title: Comments on Core 12
I
entirely support Tim's recommendation for adding 'authorization by signature' as
another authentication protocol. As a potential (quite likely) user of
SAML products, Identrus and its Banks will lean towards this model to authorize
their customers for SAML-based requests... .as this is the model used for
all other Identrus applications. Of course, the signer must be a
certificate holder of the Bank being asked the question... however, I'd presume
that we wouldn't need to specify in SAML any type of relationship between the
Signer and the SAML service.
-dan
ash
-----Original Message-----
From:
Tim Moses [mailto:]
Sent: Tuesday, August 07,
2001 5:00 PM
To: 'OASIS Security Services group'
Subject:
RE: 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
