OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Comments on Core 12

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  However, for the linkage to be verifiable, we need identifiers for the specifier type and the digest algorithm.

4 (major). Section  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  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  We should allow the "object" element to contain a digest of a data object, or the object itself.

9 (minor). Section  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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC