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

Title: RE: CORE draft 0.7 plus examples
Comments inline in red.
-----Original Message-----
From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Monday, May 28, 2001 9:46 AM
To: 'security-services@lists.oasis-open.org'
Subject: RE: CORE draft 0.7 plus examples


Outlook died twice compiling the text below; hence some of the responses may be a bit worn having been retyped three times. 

The main outstanding issue appears to be whether we need roles and attributes and whether the attributes should support some sort of structure.

I think that if we have structured attributes then we also need to allow for unstructured atoms. I don't much care about the roles/atributes issue otherwise.

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

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Friday, May 25, 2001 1:25 PM
To: 'security-services@lists.oasis-open.org'
Subject: 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.

I see these points as being essentially the same. My only reason for leaving out the facility was not being able to tie it back to an immediate requirement so I was happy to leave it for version 2.0 since it is IMNSHO inevitable that some feature of the sort will be required.

There is more than one way to support this requirement,

[A] The first is to simply cut and paste the assertion into the <Subject> field so we have <Subject><Assertion><Claims><Subject>[XYZ]. This approach is simple and direct but does not seem to achieve much since it essentially comes down to ‘you can unwrap this structure to find the information you want’. Why not just cut to the chase and specify <Subject>[XYZ] ?

[B] The problem with cutting to the chase is that it means that the application is simply told the <subject> without any information to specify where that data came from. In many audit situations one would need this type of information so that if something bad happens it is possible to work out exactly where the bogus information was first introduced and how many inferences were derived from it. So we might have <Subject><AssertionRef>[XYZ]

[C] The above is my preferred representation since the assertion can be used immediately by the simplest SAML application without the need to dereferrence the assertion reference to discover the subject of the assertion. However one could argue that an application might want to specify simply <Subject><AssertionRef> and then specify the referenced assertion in the advice container.

I think that the choice is really between [B] and [C] since the first suggestion in [A] is unwieldy and the second is simply the status quo.

Of these [B] is more verbose, [C] requires applications to perform some pointer chasing and could be seen as onerous. 

OK, I will capture this as an issue.

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.

As you say, tending towards policy. However it is important to keep in mind that we want to support SAML and XACML in a coherent framework. My belief is that the SAML subject and object elements, plus some sort of inference calculus equals XACML.  

I take the strongest exception to this. I see SAML as providing an interim, limited functionality where many of the inputs that went into a policy decision are "invisible" to SAML. For that reason I was willing to live with what I consider the very limited subject/object paradigm to avoid a protracted debate. However, if XACML is going to be chained to the limitations of whatever we specify right now for SAML, I want to raise it as an issue.
I see two issues:
1. Should the XACML be constrained to the assertion claim structure defined by SAML? Obviously this is a XACML issue, so I have copied the other list.
2. Assuming the answer to #1 is yes, Should SAML assertion claims be structured around subject/object?
For the sake of example, a resource centric claim might look something like this:
  Assertion Reference
  Authentication Method

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.

Any volunteers? 

Action Item. 

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.

Actually my understanding of the domain model is that a PEP cannot by definition ask a question about an attribute, only a PDP could ask a question about an attribute. Hence I do not see that the ‘yes but’ answer arises, at least in the PEP.

I agree that the ability to reply ‘yes but’ is useful, however I suspect that the questioner and respondent must have a common understanding of policy for the response to be useful since whatever follows BUT is essentially a policy statement. 

Hold it right there! We had an explicit vote a while back that "Yes, but..." was not permitted. The reasoning was that we don't want a extremely stupid PEP allowing something that a smarter PEP would prohibit. The PDP should return "No, but.." and a smart PEP can try again.
Tim's point in the first paragraph seems to me to be the same as DS-3-01: DoNotCache.

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.

Actually it is the policy engine that contains that information which I would expect to be controlled by the relying party domain…

However the broader answer to the point is that as I discuss later, the distinction between roles and attributes is not a sharp one and one can even argue that it is artificial.

The only point at which such a distinction can really be made is in the policy engine…

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".

That is a legacy effect from the source of the XML schema being another spec that was based on the capabilities of a specific SOAP processor :-)

I think that all the XML will need a good scrubbing.

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.

I will have a go at this, I try to work on such ‘bridging texts’ as late as possible since once written keeping them synchronized is hard work.

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


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

Shortcoming in the examples.

Perhaps you could draft out an example of the information you would like to see in one? 

The two fields we agreeded that Authentication Assertions must have are date/time of Authentication and Method of Authentication.  We could agreed that the IssueInstant or NotBefore has this semantic, but if so, this should be made explicit. To me it seems cleaner to have a distinct element, especially if you propose to allow mixing in attributes and decisions in the same assertion. Method also needs an element. Anyone want to find or propose a scheme for identifying AuthN Methods? (please no OIDs ;-). Action Item

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?"

As specified it would be necessary to extract the subject of the attribute assertion and restate (see the Tim discussion above). 

 OK, I'll fold this in with the other issue.

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.

To me all the object specifications are simply resources which have different verb relationships to the subject so I agree:-)

The reason I introduced the distinction was to allow an easy method of specifying a request for ‘all attributes’, ‘all roles’, ‘all resources’ etc.

I am quite happy to roll everything into one… or two...

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

The assertion would specify a <role> and an <attribute>. I think the need to specify more than one attribute at a time is quite clear, in the example you give the attributes are of very different types and I would expect would have quite different URIs. However I can see that an example might involve two or more closely related attributes and having to specify the URI each time would be unsatisfactory.

The attribute would be something like


Alternatively the HTML query syntax could be used to encode attribute value pairs…

Or we could extend the schema to allow <attribute> elements to specify a related value:


I don’t really mind which way it goes, the only rule I was applying was where I could not see a significant advantage one way or the other was to take the solution with the least elements… 

Ok, this is an issue. Do you have in mind that we would specific some particular set of these or just a general syntax? 

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

The AssertionID provides a unique reference for the assertion. This in AI lab ideology turns it into a first class object, which in the AI lab catechism is ‘A Good Thing ™’.

Within SAML 1.0 the principle use of an AssertionID would be to allow one assertion to reference another (see previous Tim discussion) thus allowing statements of the form ‘this assertion was constructed from that assertion’.

The principle use of the AssertionID however would be in systems built around SAML, they provide the basis for audit and accountability for example. If a system is built that allows for second order logic (assertions may be true or false and other assertions may make statements about validity (c.f. TASS meta-assertions)), then an assertionID is essential. 

You misunderstand me. I was not asking  what Assertion IDs are for in general, specifically in a query. If I had to guess, I would speculate that you want to specify the id of an assertion that already exists. If so, this should be stated. Also I would like to see some rules about what the asserting party is supposed to do if the assertion doesn't exist or if the specified assertion doesn't have the other information requested, etc.

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.

The Respond element specifies the types of element to be present in the response, that is the level of detail for the response. The other elements specify the query.  

I am sorry, I don't understand the distinction you are making.  

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

Quite probably, in fact the object element has a pretty weird schema.

I was leaving such restrictions to once we had the basic structure defined.

It is useful for an assertion to specify the Subject in more than one way. For example a common name AND an authenticator. Consider the case in which Alice is authenticated by her account ID and PIN, stands to reason that the PEP might want to prepare web pages of the form ‘Hello Alice’ while still requiring the account number. 

I raised the point, because it would be easier to understand the spec if I knew whether the sub-elements were either/or or multiple. 


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.

I have reordered the sections as follows:

1.1                 Namepaces  3

1.2                 SAML Assertion  3

1.4                 Claims  6

1.5                 Conditions  9

1.6                 Advice  11

1.7                 SAML Protocol 11



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?

By definition the Advice field can contain anything, however a SAML processor is not required to understand it. It is only required not to barf if it sees something in Advice that it does not understand.

When we have a policy language I think we will find the Advice field useful for stating the reasons why a request was permitted or denied. However I suspect that that whole area tips us into policy. 

Sounds good, can you document this? 

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?

I forget why I changed to permissions, we can go back to action if people agree.  

OK, I will capture this as an issue.

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.)

Fixed, I agree I don’t care for the term, listened to too many wishy washy OOPS talks where the term was waved like a magic wand. Could not think of anything better either.




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

Powered by eList eXpress LLC