Hello,
I agree on the limitations described below by Jeff. My concern was with the
emphasis on authentication throughout the draft, but I had in mind that it
was actually targeting that particular point (in the same way that
sip-paying targets payment).
Nevertheless, are there ideas to develop new drafts on further cases for
SIP/SAML? In my personal opinion, the protocol offers many technical
advantages (and flexibilities) that could be required for more general use
cases. By adopting and developing new cases, the overall protocol would only
be gaining a larger market share and could very well adopt some synergy
among the different areas.
As for Sebastian, I have the impression that he would like to see more
integration and deployment details. I had problems to fulfill the gaps on
integration while working on my thesis (e.g., enveloping SAML assertions in
SIP message - usually workflows target the transaction state and avoid
mentioning how to converge that with SIP - I did my implementation in the
way I thought best, but every developer is free to choose different formats
if specification does not define these little details).
As for your final points, agree to limitations due to complexity and partial
fulfilment of RFC4484. If further work is to be applied on the draft, I
believe the best action would be to leave the draft as it is and start
another work from scratch.
Regards,
Marcos
PS: I am rusty on software architecture. Can we describe SAML as a
framework? Isn't there a better terminology?
On 7/4/07, Jeff Hodges <[EMAIL PROTECTED]> wrote:
[this is a response to ostensibly "substantive" comments wrt the sip-saml
draft]
Marcos Dytz <[EMAIL PROTECTED]> said (via Hannes):
>
> 1) I believe that it would be good to leave a bit the emphasis on
> authentication and providing different uses of the protocol
Sebastian Felis said (via Hannes):
>
> In my point of view, the draft focuses only on trait-based
> authorization and tries to deploy trait-based authorization using SAML.
> It does not try to specify SAML over SIP, which I was expected.
I'm assuming that both of the above are essentially saying:
Perhaps the SIP SAML Profile should be generalized so it may be applied
to other use cases in a SIP context.
yes?
This spec is presently designed for a fairly narrow use case, derived from
RFC4474 "SIP Identity", and RFC4484 "Trait-Based Authorization
Requirements for
SIP". This use case is summarized in section 4 of draft-ietf-sip-saml-02
like so..
4. Specification Scope
The scope of this specification is:
o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
that a subject's profile attributes, and their domain's
certificate, can be conveyed to a relying party using SAML. In
doing so, satisfy the requirements outlined in [RFC4484], and
compose with [RFC4474].
Which arguably leaves essential things unsaid, such as..
- "using SAML" here means "using a SAML assertion", not using one of the
existing SAML profiles. This is a _new_, SIP-specific, SAML profile.
- we're _not_ trying to concoct a fully-general "authorization mechanism"
as imagined in RFC4484. Rather, we're simply trying to provide a means
to convey (some undefined (sub)set of) a subject's profile attributes
in the specific context of "authenticated identity management" as
defined
in RFC4474. As such, -sip-saml-02, presently meets (only) a subset of
the requirements in RFC4484. For example, Requirement 3 of Section 5 of
RFC4484 stipulates that an authorization assertion must be deliverable
to a SIP UAC either by reference or by value, and -sip-saml-02
presently defines by-reference only.
- enhancing -sip-saml-02, meaning the "SIP SAML Profile", to address
additional use cases, and/or fully meet RFC4484's requirements,
would add significant complexity to the specification.
So, if the WG were to decide that -sip-saml-02 ought to, at this time,
address
additional use cases, and/or fully meet RFC4484's requirements, then we
need to
do yet more significant work on it. Otherwise, it seems fairly close to
being
complete.
Thoughts?
=JeffH
ps:
Just to clarify on this comment..
> It does not try to specify SAML over SIP, which I was expected.
This seems to me to be indicative of a misunderstanding of SAML, because
the
phrase "SAML over SIP" doesn't make much actual sense. SAML per se is not
"just
a concrete protocol" that can be simply layered above another protocol, as
HTTP
is layered over TCP. Rather, it's a _framework_, that must be profiled for
particular contexts of use, e.g. SIP Authenticated Identity Management.
Sometimes folks, when thinking of SAML, are thinking of just one of the
existing SAML profiles (e.g. Web SSO) and imagining that to be "SAML" or
"the
SAML protocol", and further imagine said "protocol" somehow being layered
over
some other protocol. This line of thinking wrt SAML isn't workable. Rather
one
needs to think in terms of making use of applicable pieces of SAML's
"abstract
classes" (in the "SAML core" specification) and freshly concretely
applying
them to the target use case and protocols, thus crafting a new SAML
profile(s)
(and binding(s)) -- which is exactly what -sip-saml-02 does.
See also..
How to Study and Learn SAML
http://identitymeme.org/how-to-study-and-learn-saml/
---
end
_______________________________________________
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
