Subject: [Sip] Initial review of sip-saml draft

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 10 May 2006 11:41:46 -0500

Hannes: Here are initial comments based on the review of sip-saml
I-D (-05).  Thanks for getting this out.

I hope these are helpful.  I have divided them into a nits
section (further down below) and a substantive comments
section, which follows next.

1) In Section 1 itself, you may want to give a reference for
     "authorization certificates".  I presume you meant rfc3281?
     Also, a reference for SPKI may help.  I presume you meant
     rfc2692 and rfc2693.  However, these are experimental RFCs,
     and I am curious whether there are any deployments.  These
     do make for interesting reading, though (especially rfc2693).

2) I would actually put the current Section 3 *after* the
     current Section 4.  The reason is that in Section 4, you define
     the terms (SAML profile, SAML binding, etc.) that are used
     liberally in Section 3.  Thus, if you put Section 4 first, your
     reader will have a better idea of what you are talking about.

3) I believe that the first paragraph in Section 5 is very
     important since it provides guidance on why this specification
     is needed at all.  Maybe some terse editing to further highlight
     this will help.  Something along the lines of:
       Current use of SAML is strongly tied to its use with HTTP-
       based web browing.  This is a natural outcome of its
       evolution.  However, the next step in this evolution is using
       SAML in other contexts and protocols, such as Internet session
       signaling and SIP.  While SIP is closely related to HTTP, it
       is distinct enough that a new SAML profile or profiles will
       need to be specified.  Fortunately, this should not cause a
       problem since both SAML and SIP are designed to be extensible
       protocols.

4) Section 6.1.  So, when I read the description, I am left to
     wonder what are Alice's "profile attributes" that the PSTN/SIP
     gateway provider imparts to Bob.  Could you give some examples?
     Otherwise, all that I can think of is Alice's identity, which
     can be imparted to Bob.  And doing so will not require SAML.

5) In Section 6.3, it is stated that "The Offer contains
     information about the three parties...".  As far as I can see,
     the offer contains information about two parties: the merchant
     (Bob) and the user (Alice).  The third party -- Payment Provider --
     is brought into the equation with the Receipt (in step 4).

6) In section 9, there is an example of a signed SAML assertion.
     What is it asserting?  I am unable to tell, and I suppose
     others may be as well.  Maybe adding a quick text on what the
     example is asserting and tying this example to some of the
     security measures discussed in Section 10 may be helpful (for
     example, Section 10 talks about how an assertion can be
     restricted to a certain set of receivers (audiences).  How-
     ever, the <AudienceRestriction> element in the example is
     empty.  I guess it would be good if the example be a little more
     fleshed out and tied into Section 10 and/or portions of use-
     case scenarios discussed in Section 6.

NITS:

1) Section 1,
     s/SPKI or extensions to the authenticated identity body [RFC3893]/
     SPKI, extensions to the authenticated identity body [RFC3893], and
     SAML/

2) In section 2, s/concocted/defined.  "Concocted" is more of a
     colloquial term; "defined" or "used" fits much better here.

3) In section 2, s/moral equivalent/logical equivalent.

4) In section 4, first paragraph, s/regarding an assertion/an assertion

5) Section 6.1, first sentence: s/Bob, which/Bob, who

6) Section 6.2, s/user who routes its/user who routes his or her
     or alternatively, substitute with "user agent who routes its"

Hope this is helpful.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 11 May 2006 15:13:07 +0200

Hi Vijay, 

thanks for your review. 
 
>      do make for interesting reading, though (especially rfc2693).

You are right that a few references would not hurt.
I don't know a lot about the deployment of attribute certificates. 

>      reader will have a better idea of what you are talking about.

That seems to be OK for me. 

>        problem since both SAML and SIP are designed to be extensible

Sounds good to me. 
It took me also some time to understand the details of the SAML profiles
and bindings. 
To be honest: Working together with the SAML authors helped me a lot. 

>      can be imparted to Bob.  And doing so will not require SAML.

These examples are taken from the trait-based authz draft. 
When we wrote the document it seemed to be a good idea to include these
examples. In the meanwhile I am not sure anymore given that we have
documents that describe the aspects in more detail. 

For now, I still would keep them in there. 

>      is brought into the equation with the Receipt (in step 4).

You might want to take a look at the SIP Payment draft. The offer
indicates the merchant, the customer and the preferred payment
provider(s). 

>      case scenarios discussed in Section 6.

We initially included it to give the reader an idea what a SAML
assertion is.  
I don't want to put an assertion based on a specific extension (such as
a payment assertion) in there. 
Maybe we can put some authentication traits into the example. 

>      or alternatively, substitute with "user agent who routes its"

We will fix it. 

> Hope this is helpful.

Thanks a lot. 

Ciao
Hannes