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:]
Sent: Monday, May 28, 2001 9:46 
  AM
To: ''
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:]
Sent: Friday, May 25, 2001 1:25 
  PM
To: ''
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:

 

Evidence

  Assertion 
Reference

  Authentication 
Method

  
Date/time

  
Intermediaries

  
Location

  Subject

Resource

  Object

  
Operation

  
Signature

  
Instance

 

  

  
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.  

  
Fixed

  

  
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:] 
  
Sent: Thursday, May 24, 2001 10:49 AM
  
To: 'Phillip Hallam-Baker'; 
  '' 
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. 

  
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 

  
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:

  
urn:dns-date:2001-02-04:3947298?transaction_limit=USD500

  
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. 

  

  
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. 

  
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

  
 

Great

  

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

  
Fixed

  

  
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.

  

  
Regards, 

  
Hal  

Hal