Re: [Sip] saml proposal

["Andreas Pashalidis" <Pashalidis at nw.neclab.eu>]

Dear James, all,

We apologise for not clearly stating the purpose of draft-pashalidis-sip-saml-00 and its key differences with draft-ietf-sip-saml-04.txt - we should have done that.

> [...] making me question why the new ID was written [...] [...] asking 
> if you can explain the need for this second SAML in SIP ID [...]

We wrote this ID having in mind the following main use case (among others).

The user wants to register with his SIP proxy, and is then put in contact with his IdP to perform authentication. 
The IdP provides authentication (as a service) but is not itself a SIP proxy. In general, the IdP provides authentication and user attributes to a multitude of service providers (including SIP proxies, webservers, and other types of service).

In other words, we would like to have a solution where the authentication is offloaded to an IdP, and where the relevant messages are SAML messages. We do not think that this competes or interferes with other user authentication mechanisms for SIP in any way. The reason why would like to have the messages encoded in SAML is because this is likely to maximise overall interoperability (and hence, positively affect overall user experience) since one can make the system work with any SAML-based IdP with limited effort. Having a SIP proxy accept a SAML authentication assertion means that we can have Single Sign-On *across* application domains (e.g. across HTTP and SIP) - this is what we would like to have. 

The main differences of draft-pashalidis-sip-saml-00 and draft-ietf-sip-saml-04.txt are as follows (according to our current, perhaps limited, understanding).

1. the former addresses the main use case above; the latter doesn't because it only allows the exchange of attributes (and "trait-based authorization" 
somehow conveys the message that the user's authentication status is NOT regarded as an attribute, i.e. explicitly excluded) 2. the former focuses on the SIP REGISTER method; the latter focuses on the SIP INVITE method 3. (as a side-effect of 2:) the former focuses of the provision of user authentication and attributes  to the SIP proxy of the *caller*; the latter focuses on the provision of attributes to the *callee* (or its SIP proxy) 4. the former specifies how to carry SAML over SIP, in a fashion that is similar to the way that HTTP has been specified to carry SAML. The advantage of SIP carrying SAML messages is that SIP UAs or SIP proxies do not need to implement two different transport protocols (SIP and HTTP), as is currently required by draft-ietf-sip-saml-04.txt. However, this could be easily added to the existing WG doc as well (at least we think so).

As to the why we submitted this draft, we wanted to support these activities which we think are important and fit to our current use of SIP and SAML. The current WG doc has a scope founded by rfc4474 and rfc4484 which does not cover all the use cases we'd like. Perhaps those are outside the scope of the WG, we think that's the discussion we'd like to have. 
The draft should be seen as input on this topic rather than competing or a statement of disagreement.

The other reason to submit this draft was to try and rekindle the discussion on the use of SAML in the context of SIP (it's recently been rekindled enough :)). We believe it is very important to have a consistent view on SSO and attribute exchange - a view that is consistent across platforms and, as much as possible, application domains.

Best Regards,
Andreas & Joao

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip