Completeness Specifier

Title: Editor comments on Core-12

At 
present people are getting confused about the completeness specifier. I propose 
to change the permitted values to fit the semantics better

 

 All ---> AllOrNothing
1.1.1.1            
Simple Type CompletenessSpecifierType 

The CompletenessSpecifierType type is used in a 
request to specify how a service should respond in cases where a client makes a 
request and the client is not authorized to receive part of the response. The 
CompletenessSpecifierType type defines 
two possible values ”Any” and ”AllOrNothing”.

If Any is specified AND the 
client is not authorized to recieve part 
of a response:
The response contains the parts of the response 
that the client is authorized to receive.

If AllOrNothing is specified AND the client is not 
authorized to recieve part of a 
response:
The response is empty.

The following schema specifies the <CompletenessSpecifierType> type:

   <simpleType 
name="CompletenessSpecifierType">

      <restriction 
base="string">

          <enumeration 
value="Any"/>

          <enumeration 
value="AllOrNothing"/>

      </restriction>

   </simpleType>

 

Phillip Hallam-Baker FBCS C.Eng.
Principal 
Scientist
VeriSign Inc.

781 245 6996 
x227

  
-----Original Message-----
From: Hallam-Baker, Phillip 
  [mailto:]
Sent: Tuesday, August 07, 2001 1:10 
  PM
To: 'Orchard, David'; 
  
Subject: RE: Editor comments 
  on Core-12

  
In order to clarify (2) as discussed I have made the 
  following modification to the text, does this clarify 
  matters?

  
 

  
 

  
A 
  SAML processor will return a certain number of Authentication Assertions in 
  response to a SAMLQuery 
  of type AuthenticationQueryType. 
  The <Subject> 
  and <AuthenticationCode> 
  of the returned assertions MUST be identical to the subject (and optional 
  <AuthenticationCode>) 
  fields of the SAMLQuery. 
  There is no implication that all such assertions must be 
  returned.

  
 

  
 

  
A 
  SAML processor will return a certain number of Authentication Assertions in 
  response to a SAMLQuery 
  of type AuthenticationQueryType. 
  The <Subject> 
  of the returned assertions MUST be identical to the subject (and optional 
  <AuthenticationCode> 
  if present) fields of the SAMLQuery. 
  There is no implication that all such assertions must be 
  returned.

  
 

  
Phillip Hallam-Baker FBCS C.Eng.
Principal 
  Scientist
VeriSign Inc.

781 245 6996 
  x227

  
    
-----Original Message-----
From: Orchard, David 
    [mailto:]
Sent: Monday, August 06, 2001 
    6:15 PM
To: 
    
Subject: Editor comments on 
    Core-12

    
I have the following comments on the Core-12 and it's 
    representation of what we agreed at F2F #3.  I have not had a chance to 
    run these issues by the other editors nor do an extensive perusal of the 
    previous minutes, but I felt it important to report before the tuesday 
    meeting.  This means I don't think that we can close the action item to 
    produce a consensus draft - because I don't consent :-(  I really 
    wanted to consent as the other editors have done a good job on the schema 
    and other documentation.   

    
I look at my responsibility as an assigned editor to 
    faithfully capture what the group agreed to.  I believe any divergence 
    from what was captured should be proposed to the group, rather than changes 
    made via editorial privilege.  Hence my comments are generally about 
    divergences between what I believe was agreed at F2F #3 and the core-12 
    document.  The changes may be valid from a technical perspective, but I 
    think they don't follow the process that we agreed to.  Or I'm just out 
    to lunch, which often happens ;-)  If it turns out these have all been 
    discussed by the TC and there are agreed upon decisions, then I clearly 
    consent to the TC will.

    
0. Any time I see a struct with top level elements, I 
    believe that at least 1 of the top level elements must be required.  
    Otherwise we used the optional notion.  In most cases, all the top 
    level elements must be required as well.

    
1. Object as described in Core-12 has resources and 
    "actions" in it, and it should be separate.  For example, 
    AuthorizationDecisionAssertionRequest from the white-board has an Object and 
    an Action, whereas the Schema has Object which contains Resource and 
    Action.  If some of the editors whish to change the notion of objects 
    to have actions, then it should be as a proposal.  As a TC member, I 
    would lobby against having object mean resource + action. 

    
  
2. A few of the structures do 
    not have quite the right cardinalities in them.  The particular 
    structures are: 
  - Authentication queries 
    should have 1 authentication code in them, not 0..1  
  - Attribute queries should have at least 1 attribute name in 
    them.  According to the actual minutes, the possibility for unbounded # 
    of attributes is excluded.  But I think this was probably a whiteboard 
    scriber error rather than an explicit TC decision.

    
  - See #4 for Attribute Queries. 
  
3. The treatment of wildcard 
    attributes is a bit confusing. I had understood that we were supporting 
    structured attributes through the XML Schema wildcard mechanism, but that is 
    not captured in the minutes nor in the schemas.  I think this means I 
    would like to raise an issue that we do not currently support attributes 
    defined using XML Schema structures.  We do support attributes defined 
    using Name/Value pairs.  Both the previous document submissions had 
    support for this construct.  We do have a wildcard for attribute value, 
    but that only means we can have structured values and not general 
    structures.  

    
4. The treatment of attribute values is a bit 
    confusing.  The minutes indicate that attributes MUST have a name and 
    MUST have 1 or more values.  But the attribute Query refers to 
    attributes and mentions XPath.  I believe this is indicating that there 
    is an Attribute query String rather than a structure.  So I do not 
    believe the attribute query can refer to an attribute, it must refer to a 
    different "type", such as an attribute Name type.  When/if we do 
    support wildcard attributes, then this will make even more sense as we'll 
    need a place for the query string like XPath.

    
Cheers, 
Dave Orchard 
    

Phillip Hallam-Baker (E-mail).vcf