Re: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt

["Jeroen van Bemmel" <jbemmel at zonnet.nl>]

Hi Hannes,

<snap>
> We have been experimenting with this in the context of Web
> services. One of  the things we found is that communicating policies 
> following
> the current standards (i.e. signed SAML assertions) leads to very verbose, 
> large
> documents.

| it depends on the content of the assertion (and whether you use assertions 
at all).
| if you use xml document then everything tends to grow in size.

| if you use an artifact then the size of the "token" is very small, in fact 
it is only a pointer to the assertions itself.

You are right that using pass-by-reference rather than pass-by-value could 
alleviate the size issue, however what do you do then about policy rules 
that are to be interpreted by the client (as in the session policies draft)? 
It seems a bit double to direct the client to a policy server, which then 
directs it to some other server for resolving the artifact.

I would suggest a hybrid approach: use a policy that contains some 
parameters to be interpreted by the client, and possibly an opaque artifact 
that is to be passed in each request. Some requirements for this artifact 
would be:

- it should contain a timestamp for replay protection
- it should contain the identity of the client to which it was given
- it should be signed
- it MAY include an indication of the source that issued it (e.g. id of its 
certificate), this could also be implicit

I'm thinking of something like an MD5-converted encrypted URL with some 
parameters

Depending on the trust model the complete token could optionally be signed 
too for verification by the client, but it may also rely on other layers 
(e.g. using https)

I would personally choose to have the proxy return such a policy instead of 
a reference to some policy server ( i.e. it sends an error reply with the 
policy as body, and maybe the artifact in some header). The client should 
indicate support for this in its Accept header. Benefit of this is that it 
does not burden the client with yet another protocol to implement for 
talking to a policy server. And for SDP related policies, why not have the 
proxy return an SDP description of what it allows (since the client already 
knows how to parse SDP) instead of adding a new XML format?

Regards,

Jeroen 


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP