RE: Comments on Core 12

[Daniel Ash <Daniel.Ash@identrus.com>]

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:tim.moses@entrust.com]
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:pbaker@verisign.com]
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.
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