RE: CORE draft 0.7 plus examples

security-services message

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.
pbaker@verisign.com
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.

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

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.

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.

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.

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

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:

Major

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

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

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.

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.

http://whatever.test/transaction_limit/USD500
urn:dns-date:2001-02-04:3947298:USD500

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…

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.

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.

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

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.

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

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.

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.

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.