RE: Comments on Core 12

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Title: Comments on Core 12

 

 

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
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