RE: [dss] Policy-wise Server profile doc

[Trevor Perrin <trevp@trevp.net>]

Hi Paul,

Sorry I didn't respond earlier.


At 11:04 AM 2/23/2004 -0500, you wrote:

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


Is it necessary for the policy statement to be signed?  I guess that stops 
the gateway from modifying the policy statement.  But does it?  The gateway 
could invent an entirely new policy statement, from scratch, that was 
similar to the signed one but different in one respect.  Or it could 
mix-and-match signed policy statements with outgoing SOAP responses.

So it seems the gateway has to be trusted to request signatures.  In which 
case, the SOAP Client in the remote domain just needs to tell the gateway 
what DSS parameters to use, and the gateway just needs to use those.  That 
wouldn't require a DSS protocol change.

I dunno, I'm just having trouble imagining a setup of trust relationships 
that would require someone besides the sender of a request to vouch for 
only the policy portion of the request.

If some other party wants to tell the sender what parameters to use, that's 
one thing, but it seems we're looking at something more subtle here..


Trevor