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: 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.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Tuesday, August 07, 2001 1:10 PM
To: 'Orchard, David'; security-services@lists.oasis-open.org
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.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Orchard, David [mailto:dorchard@jamcracker.com]
Sent: Monday, August 06, 2001 6:15 PM
To: security-services@lists.oasis-open.org
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



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


Powered by eList eXpress LLC