RE: CORE draft 0.7 plus examples

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

Title: RE: CORE draft 0.7 plus examples

Colleagues - I agree with all Hal's remarks.  Furthermore ...

1. Section 1.6.3 - The authenticator element of an assertion should be able to reference another assertion, used solely for authentication.

2. Section 1.6.4 - The role element should be able to reference another assertion that asserts the attributes of the role.

3. Section 1.6.4 - The PDP has to evaluate a boolean expression.  The applicable expression is identified with the requested resource action (or object method in object-oriented terminology).  Attributes of the principal, the resource and the environment form the domain of the expression.  The expression and the attribute values may be conveyed (in any combination) in assertions.  The form of the expression is in-scope for XACML, not SAML.  But allowance should be made in SAML assertions for conveying these XACML expressions.

4. "Examples and explanations" - Examples should cover the case of a principal requesting the issuance of an assertion containing specified claims and identifying itself as the subject.  I.e. it should illustrate the authentication of the principal to the issuer, the request for issuance of the assertion and the creation/delivery of that assertion or a reference thereto.

5. It has been pointed out that it will be common for the PEP to ask a question that is too general for the PDP to answer with an unqualified affirmative.  Instead, it will answer "Yes, but ... " or "No, however ...".  In the former case, the PEP may proceed to perform the action requested by the principal under the prevailing circumstances, but different circumstances might have elicited a different response.  Therefore, it cannot be assumed that the same question would always be answered in the affirmative.  The PEP should not cache such responses, nor should another PEP expect to obtain the same response to the identical question.  A solution to this requirement should be described.

6. Examples and explanations - The "capability model" described in the examples seems somewhat artificial.  It expects the business exchange to know about the file structure in the relying party domain.  It is more natural for the business exchange to assert some attribute values (privileges or roles) for the principal and for the relying party to associate a policy with operations on its file structure.

7. Section 1.2.2 - The bulleted list of characteristics for the ticket must contain a locator for the corresponding assertion. 

8. In several syntax definitions, elements are named "string".  It would be more helpful to give them a meaningful name with the type "string".

9. Examples and explanations - It would be helpful if the examples were to identify the components of the domain model and how they may be combined.  For example, when the PDP is combined with the Issuer or with the PEP.

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, May 24, 2001 10:49 AM
To: 'Phillip Hallam-Baker'; 'security-services@lists.oasis-open.org'
Subject: RE: CORE draft 0.7 plus examples

Comments on draft-sstc-core-07:

Major

1. I don't see any support for Authentication Assertions.

2. I don't see any way to request something like "Can the person who is the
subject of this Attribute Assertion (included or referenced) access X?"

3. What is role? Why does it have a distinguished place in the request
structure? To me, Role is just another atttribute, like Group, Clearance,
Transaction Limit, etc.

4. I don't see anyway to specify Attribute values. I want to be able to say
Group = Admin, Transaction Limit = $500.

5. In 1.3.1 I don't understand the intended purpose of AssertionID.

6. Also in 1.3.1 I don't see what Query, Conditions and Advice are supposed
to do, they seem to have been subsumed into Respond.

7. Shouldn't <choice> be used in some places where <sequence> appears, for
example, 1.6.2 Subject or 1.6.4 Object?

Minor

8. The order of the document makes it hard to follow. It begins on
Assertions, then Requests and Responses, which include Assertions, then back
to Assertions. Assertions are described as having Basic Info, Claims,
Conditions, Advice, but the section order is Conditions before Claims.

9. In 1.6.4 2nd para, 2nd sentence, reads  "In the case of an attribute the
relationship is that the subject has the specified object." I think you
meant:  "In the case of an attribute, the relationship is that the subject
has the specified attribute."

10. Should Advice be able to contain something other than Assertions?

11. I don't care for "permissions" in 1.6.5. The examples suggest that what
is meant to go here is "action" or "operation". Why not use one of these?

12. In 1.6 the second sentence ends "the <Authority> element." I think it
should be "the <Binding> element." (I don't care for this use of "binding",
but can't think of anything better.)

Regards,

Hal

> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Monday, May 14, 2001 2:46 PM
> To: 'security-services@lists.oasis-open.org'
> Subject: CORE draft 0.7 plus examples
>
>
> All,
>
>       I have made some minor corrections to typos that were
> pointed out in
> the 0.6 draft and revised the examples and explanations draft
> to match the
> core draft.
>
> This corrects the following problems:
>
> * Issuer incorrectly typed 'issue' in schema
> * Failed to remove Validity depends upon from one of the
> schema fragments
> * Failed to update the Authorization tag and the binding tag
>
>       The draft still incorporates the protocols section
> pending new text
> from Tim Moses.
>
>       The main issue in my mind is defining the request structure.
>
>       I have not expanded on the password auth passthrough scheme that
> steve and I have worked on. However people will note that the 'ticket'
> example now uses the <Authenticator> mechanism.
>
>               Phill
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> All,
>
>
>

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-services-request@lists.oasis-open.org