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: 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, 
> 
> 
> 


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


Powered by eList eXpress LLC