RE: [dss] Policy-wise Server profile doc

[Paul Madsen <p.madsen@entrust.com>]

Hi Trevor, inline for responses

Paul

>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: Sunday, February 22, 2004 6:33 PM
>To: dss@lists.oasis-open.org
>Subject: Re: [dss] Policy-wise Server profile doc
>
>
>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?

Nb: I incorrectly wrote <ServiceProfile> above rather than <ServicePolicy>

I'll take a stab. High level, I think we need a general purpose policy
container that, in the absence of a standardized mechanism, can support a
variety of policy expression languages.
 
>
>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?

Use Case

1) SOAP Client in remote policy domain sends SOAP Request for some
application - request includes security policy for eventual response -
policy specifies client's policy for particular elements to be signed in
subsequent response. Policy statement is signed.
2) SOAP Request intercepted by SOAP Gateway, clients policy requirements
extracted and stored. SOAP Gateway forwards on request to application
3) Eventual outgoing SOAP response is intercepted by SOAP Gateway. gateway
builds DSS <SignRequest> to send to DSS Server,  
4) SOAP Gateway sends <SignRequest> to DSS Server, includes previously
cached policy statement
5) DSS Server validates signature over policy statement, determines
appropriate intersection of policies, signs accordingly.
6) DSS Server sends <SignResponse> to Gateway
7) SOAP Gateway returns SOAP Response to SOAP Client.

 

>
>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
>
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_
workgroup.php.