> -------- Original Message --------
> Subject: [Sip] SIP SAML Review by Richard Barnes
> Date: Wed, 20 Jun 2007 23:44:26 -0400
> From: Richard Barnes <[EMAIL PROTECTED]>
> To: IETF SIP List <[email protected]>, Hannes Tschofenig <[EMAIL PROTECTED]>
>
>
> Figure 2:
> In the INVITE messages, the AoR in the From: header should be
> "sip:[EMAIL PROTECTED]"
ok.
> Section 6.1.2, Step 3:
> The AS is supposed to insert "attributes required by Bob's domain". How
> is it supposed to know which attributes these are? This is answered by
> the following paragraph, which should be moved up to here.
ok.
> Section 6.1.2, Step 3:
> The AS constructs a "HTTP-based SAML URI reference" -- shouldn't this be
> a reference according to the binding defined in this document, instead
> of the original (SAMLv2) reference standard?
nominally yes, will investigate.
> Section 6.1.3.3, third paragraph:
> This paragraph gives the option of HTTPS or HTTP, but doesn't specify
> that one of the two MUST be used. Suggested text: "The AS MUST
> construct either an HTTP or HTTPS URI per Section "3.7.5.1 URI Syntax"
> of [OASIS.saml-bindings-2.0-os]. It is RECOMMENDED that the AS
> construct an HTTPS URI."
good catch.
> Section 6.1.3.3, fourth paragraph:
> This is not technically correct; the URI should be the absoluteURI
> portion of the Identity-Info header value.
another good catch.
> Section 6.1.4:
> Through out this section, situations with exceptions are presented as
> "SHOULD ... MAY ...". As I read it, this creates a situation without a
> mandatory default behavior; I would prefer if these were worded as
> MUSTs, with MAYs allowed under specified circumstances.
will re-think with eye towards mandatory default behavior.
> Section 6.1.4.1.3:
> The SHOULDs in this section should be should be MUSTs.
nominally agree.
> Section 6.1.4.1.4, second paragraph:
> This needs to say that the attribute-value pairs MUST pertain to the
> subject of the assertion (a concept which needs to be tied to a SIP
> entity elsewhere in the document). This may be the entity identified in
> the From header, or another identified entity.
nominally agree.
> Section 7:
> This binding doesn't really have anything to do with SIP.
agreed.
> Could we just
> exclude SIP from the name?
sure.
> Maybe this could be the IETF standard URI
> binding of SAML.
that's an interesting thought, tho I wonder if it is worth the effort to try to
do as an I-D on its own -- it's so small to specify that it can easily be
included by-value in other specs, but of course then there might be skew, but
would that in actuality be a problem, ... etc. And more precisely it's an
http-uri-based one. there could be other needs for schlepping saml assertions
via http in other fashions.
thanks for your insightful review.
=JeffH
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
