Re: [dss] Policy-wise Server profile doc

[Trevor Perrin <trevp@trevp.net>]

At 08:46 AM 2/17/2004 -0500, you wrote:

>Hi, enclosed is the Policy-wise Server Profile, based on Trevor's profile 
>template.
>
>Currently, I deal with the possibility of an external policy authority 
>defining the signing/verifying policy for the DSS client to include in its 
>requests through an allowed ds:Signature within the OptionalInputs 
>element. Prefereable would be to use a modified ServiceProfile element 
>containing this policy.

You and Frederick discussed this earlier.  Would you like to flesh it out 
into a proposal for the core?

Some rationale or use cases would be helpful for people who aren't familiar 
with "external policy authorities" (like me :-).  Why would policy be 
configured at a policy authority instead of the DSS server?

I'm also curious how the client proves, to the DSS server, that he is 
allowed to produce signatures under this policy.  It seems like the "policy 
statement" needs an embedded access-control statement?


>I had planned on creating a corresponding schema to reflect the 
>constraints but to do so would have required the introduction of two new 
>elements SignOptionalInputs and VerifyOptionalInputs to reflect the fact 
>that policy-wise sign and verify requests would have different 
>constraints. This seemed contradictory to the core model.

If you wanted to create a corresponding schema, you could just 
copy-and-modify the current schema, and redefine SignRequest/OptionalInputs 
and VerifierRequest/OptionalInputs to be more specific types.  I.e. instead of:

<xs:element name="OptionalInputs" type="dss:AnyType"/>

<xs:element name="SignRequest">
     <xs:complexType>
         <xs:sequence>
             <xs:element ref="dss:OptionalInputs" minOccurs="0"/>
             <xs:element ref="dss:InputDocuments"/>
         </xs:sequence>
         <xs:attribute name="RequestID" type="xs:string" use="optional"/>
     </xs:complexType>
</xs:element>


You could have:


<xs:complexType name="SignOptionalInputsType">
   .
   .
</xs:complexType>

<xs:element name="SignRequest">
     <xs:complexType>
         <xs:sequence>
             <xs:element name="OptionalInputs" 
type="dss:SignOptionalInputsType" minOccurs="0"/>
             <xs:element ref="dss:InputDocuments"/>
         </xs:sequence>
         <xs:attribute name="RequestID" type="xs:string" use="optional"/>
     </xs:complexType>
</xs:element>


>  Related, can somebody tell me what was the motivation for modelling 
> OptionalInputs as dss:AnyType rather than as appropriately extendable 
> sequences of child elements?

The biggest problem with using derived schema types for OptionalInputs, I 
think, was that we need to support:
  - concrete profiles inheriting from multiple abstract profiles
  - restricting *or* extending them.

I don't think you can do those things with schema types.  If I'm wrong, or 
you're thinking of something else entirely, let us know.


Trevor