> -------- Original Message --------
> Subject: [Sip] Comments draft-ietf-sip-saml-02
> Date: Thu, 21 Jun 2007 16:47:46 +0200
> From: Willekens, Marc <[EMAIL PROTECTED]>
> To: <[email protected]>
>
>
> [Page 3], Introduction
>
> Is this document only about assertion for the authorization or also for
> the authentication?
authorization.
> [Page 12]
>
> Domain name for Alice: example.com or foo.com?? (same comment for other
> figures)
oops, good catch. foo.com.
> Authentication service or Assertion service or both?
authentication service -- the term is from rfc4474.
> [Page 13], 6.1. Assertion Fetch profile
>
> Is this the only planned profile or will other profiles be defined and
> added later?
My personal present thinking is that there are other possible SIP SAML
profiles, e.g. see the appendix in -sip-saml-02 of other use cases, but that
they should likely be specified separately in their own drafts.
> Will there also be a push based model? Will it then be
> "pushed" as part of the SIP message?
This is something for the WG to think about. One _can_, in theory, have the UAC
assert some information and attach a SAML assertion to a SIP request (e.g.
Invite) body making such a statement. Thus this approach could only be used by
UACs because (1) only UACs may place data in the SIP request body, and (2)
there are vociferous objections in the SIP WG to schemes whereby SIP
intermediaries may place BLOBs (binary large objects) in SIP header fields. See
also..
[Sip] wrt SIP Saml Review by Jiri Kuthan - "missing scenarios"
http://www1.ietf.org/mail-archive/web/sip/current/msg19793.html
We could specify this for UACs-only, and the other http-uri-based fetch
approach for, as it is currently, intermediates or UACs.
However, before we go to the effort, what's the in-actuality demand for doing
so? Has anyone implemented the rfc4474 authentication service role in the UAC
and is it being used?
> [Page 13], 6.1.1. URN
>
> What's the current consensus for the urn?
No one has objected to what is in the spec, although no one has commented
specifically on it as yet, either.
> [Page 17], 6.1.3.
>
> ...sender and Authentication service (AS) may be separate or... ???
>
> How will the AS and sender be combined?
See the last paragraph on page 5 of rfc4474..
"This specification allows either a user agent or a proxy server to
provide identity services and to verify identities."
> [Page 22], 6.1.4.1.4.
>
> AttributeStatement is indicated. But what about Authentication and
> Authorization Decision statement?
This particular SIP SAML Profile doesn't specify use of those statements, but
they are not explicitly excluded either. Conceivably someone could cook up a
use case for them and make use of it in a site-specific manner, or we might
find use case and then can specify their use more easily.
If we do want to explicitly do this we should perhaps add that such statements
MAY be present, but their meaning is defined outside of this profile.
> [Page31]
>
> This RFC draft talks about assertions. But how can an identity be
> asserted only by considering a device, e.g. in case a device is stolen
> or temporary used by someone else? At VON 2000, H. Schulzrinne has
> already indicated that something as fingerprint has to be added for a
> device with a changing set of owners.
Although a valid thought, that being the question of the nature of the actual
authn mechanism between the UAC and the registration service, it is out of
scope of this specification. In fact, this draft nowhere states that the
subject's identity is asserted only by the device (UAC).
thanks for your 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
