Comments on Core 12

[Tim Moses <tim.moses@entrust.com>]

Title: 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."

2 (minor). Section 1.  Attribute assertion.  Is there a reason for saying "is associated with", instead of "possesses"?  "Possesses" seems more straight-forward.

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.

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.

5 (minor). Section 1.3.2.1.  Can we be more specific about the use of "AuthData"?

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?

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?

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.

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?

10 (major). Section 1.7.2.  "Audience" should be able to specify a "use", as well as a "community".

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.

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.

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".

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.

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.

------------------------------------------------------------------------
---------------
Tim Moses
Tel: 613.270.3183